The event flow for actions
This section covers the order in which action commands are run in event declarations. In general, it is pretty obvious - the commands are run in sequence flowing downwards through your config.
But in the case of running target selectors, in exactly which order do commands run?
This is important to know if you need to incorporate pauses or delays and need to know what sequence the event flow takes by default.
Let's take this scenario:
If you had four spans, would it run all of the commands on the first span, then all commands on the second one, etc.?
Or would it run the first command on the first span, the first command on the second span, etc. then run the second command on the first span, the second command on the second span, etc.?
Here is the answer:
Span tag 1: runs background-color: blue;
Span tag 2: runs background-color: blue;
Span tag 3: runs background-color: blue;
Span tag 4: runs background-color: blue;
Span tag 1: runs color: white;
Span tag 2: runs color: white;
Span tag 3: runs color: white;
Span tag 4: runs color: white;
See this example below to see it in action. The await option on the after 1s action commands - operating on 4 separate span tags from a click event - makes the event flow easy to see. Remember, there is only one event flow running here. This example visually demonstrates the exact flow the core takes when iterating through your config commands. Normally you wouldn't even notice this, but when you start using pause and await this information becomes quite important, so that you don't go "Huh?".
Using the "await" option in a single event with multiple targets
The flow is always per event. Then iteration occurred on each target selector sequentially within that one event.
If you set off multiple events at the same time, you get a separate flow for each event.
This next example is pretty much exactly the same, but because the event is the draw event, it actually runs 4 times. There are 4 event flows, so each span tag is actually working independently from all the others. So you get a different effect even though the action commands are exactly the same.
This is a little bit harder to read. You generally would never need to use this technique - you would use the pause command to do the same thing, but in a simpler way. This example, however, demonstrates that the event flow runs per event. And you may find yourself doing this by accident and not understanding why it works like this and not per the example above. There are 4 events running here, so the animations work in parallel...
Using the "await" option with a single target in multiple events
That should clear up which sequence the event flow takes during regular operation. The browser usually executes action commands fast enough so that everything looks like it's happening at once, so you may not have fully realised that action commands flow in the way they do.
How to get separate target selector event flows
Maybe you have a scenario that is similar to the first example shown above, but you need the target selector event flows running simultaneously, as if each target selector element had its own event flow. You can do this too, in a way that is easier than triggering separate events for each target element.
By using the pause command, you can simulate a separate event. You can make each target selector flow through the config "downwards" at the same time, in parallel.
What happens here is that the pause command effectively breaks out of the event flow and resumes after the given time, giving the other target selectors a chance to catch up. Through doing this we can get target selectors appearing to have their own event flow and operating simultaneously.
See this example:
The "pause" command
It depends on what effect you are trying to create. You can use "await" for one scenario, or "pause" for another, or a mixture of both.