Set up a syntax for target selector action groups to be run after stack

[bob2517]

An example of this would be for when using reactive variables. Like you need something to happen after making variable changes and need to wait until all the updates are done before running some actions on a target. Reactive variables have their own event flow when updating.

The workaround is to run a trigger on a custom event after stack. It's a mild inconvenience.

A simple "after stack" at the end of the target selector would be the indicated syntax to be consistent with the action commands.

Eg.:

pagination-links a[data-current-page="{$currentPage}"] after stack {
    take-class: .currentPage;
    pause: 1s;
    #status {
        render: "what just happened";
    }
}

Obviously this wouldn't just be after stack, it could be "after 1s", etc. I don't have a use case for adding "every" yet.

[bob2517]

This would be good - occasionally run into this and have to find a workaround. Tagging for 2.15.0

[bob2517]

Note to self: explore using the existing pause and timer flow for this by triggering a pause as usual, but breaking out at the end of the target selector via a flag, or something like that - that's got to be the simplest way to do it to allow for pause commands within the delayed target event.

[bob2517]

Will include label support for cancelling.
Internally this will probably be a mix of pause and "after/every" code. The resumption queue will be used to restart the event flow after a delay, but will not continue the full event flow after the target command queue is done, at which time all the commands in the target queue will "forget" they have been run, by resetting the flags. This should allow "every" to work when the same resumption happens again on an interval, and it should work with pause commands inside the target command queue. Something like that.

[bob2517]

Update:
I've got the following code working as expected offline, plus a separate test for cancelling delayed target events via a label, so the bulk of the work is done for this. The pause command is where things get interesting in the core, due to its asynchronous nature. This just needs some more expansive tests before a commit (like making sure the "parallel" event flow works, conditional statements, and for targets in components) which I'll do over the next few days.

body:init {
    render-after-begin: "<p>The div below will populate after 3 seconds, and then run a sequence.</p>";
    div after 3s label divthing {
        render: "Hello";
        pause: 1s;
        render: "Hello again!";
    }
    render-after-begin: "<p>Something at the top.</p>";
    section after 4s {
        render: "There";
    }
    render-after-begin: "<p>Something higher than the top.</p>";
    pause: 5s;
    render-before-end: "<p>Something at the end!</p>";
}

[bob2517]

Outstanding: Fixing a bug with "after" plus "every" on a parallel event flow with multiple targets with pause commands inside. Like "span every 6s after 2s parallel". After this I'll push it into the branch and try refactoring some things to see what happens.

[bob2517]

This looks done now, but will do final tests and if all goes well put on the branch tomorrow.

Note to self: Possible expansion on this could be for @every 1s { ... } and @after 1s { ... } statements to wrap actions and target selectors, but test the target delay in production first and work with it for a while to see if it comes up as something that could be handy.