Allow directives (actions/transitions/animations) to be more dynamic

[dummdidumm]

Describe the problem

Svelte encourages reactivity at many levels, but when it comes to actions, transitions, or animations, it's rather static:

• you are not allowed to swap out one directive for another at runtime. Doesn't work for actions, does work for transitions/animations only when they are not rendered
• you can't conditionally apply a directive by setting it to undefined; it will throw a runtime error
• attributes are not always updated, related to #3633

Describe the proposed solution

Support swapping out directives

Alternatives considered

Workaround code involving #ifs

Importance

nice to have

[Prinzhorn]

Related https://github.com/sveltejs/svelte/issues/6754

[bartektelec]

Not directly an issue with Svelte itself, but...

If this gets merged and lets you apply undefined to a transition: it could possibly mean this will be solved as well:

https://github.com/testing-library/svelte-testing-library/issues/206 Where the only workaround I found was to explicitly create two different elements - one for testing and one for real use.

        {#if import.meta.env.VITEST}
          <div data-testid="alert" role="alert">
            ....
          </div>
        {:else}
          <div
            data-testid="alert"
            role="alert"
            transition:fly 
          >
            ....
          </div>
        {/if}

notice the transition can only be applied if not in VITEST env, if any kind of transition: directive is applied the tests will fail

[tivac]

This would still be really nice, actions are super-powerful but weirdly static compared to how reactive the rest of svelte is currently.

[Azarattum]

It would be great if we could also have an imperative transition API as an escape hatch for advanced use cases. I would really like to have manual control over:

• pausing/resuming effects (keeping unmounted component in DOM for some time)
• pausing/resuming navigations (having 2 pages in DOM at the simultaneously for some time)
• applying transitions imperatively to runtime elements that are unknown (e.g. children of a snippet)

Now these framework features are exclusive to transitions. Having an explicit API would open many possibilities for library authors.