Allow transitions to skip intro/outro #1700
Conversation
jacwright
force-pushed
the
gh-1480-alt
branch
2 times, most recently
from
07115e6 to
9b18388
Compare
Allows transitions to skip running when they are added to the DOM or removed from it. Similar to the compiler option `skipIntroByDefault` this allows the intro/outro to be skipped.
Example:
```html
{#if visible}
{#each things as thing}
<div transition:fade></div>
{/each}
{/if}
<script>
export default {
transitions: {
fade(node, params) {
return {
intro: false,
outro: false,
duration: 400,
css: t => {
return `opacity: ${t}`;
}
};
}
}
};
</script>
```
In this example items in the each-block will fade in and fade out when they are added to or removed from `things` but the list will appear suddenly and disappear suddenly (no fade) when `visible` is toggled to `true` or `false`.
This is another try at #1480 from the compiler option in #1692.
Intro and outro transitions will run unless `intro` or `outro` on the transition object (e.g. next to duration/delay) are set to false. Transition defaults can be set in the root options, including intro and outro.
|
To illustrate the need for skipping intros/outros I've put together 2 gifs of my app, one with them and one with out (with this PR and intro/outro being false by default). I've slowed down the transition to make it more obvious in the low-quality gifs, but at normal speed it is still noticeable and makes the app feel broken/clunky.
In the above, you'll notice when the page is first loaded and later when we come back to this page, the folders animate open. They should animate, but only when clicked on by the user, not when they first appear. You'll also notice there is a very broken-looking state when moving to another page while the folders collapse in an outro animation. Both pages are visible at the same time and overlapping each other.
In this second recording it feels much better. The page transitions are immediate. The folders only animate when being opened/closed, not when appearing or being removed from the DOM. The folder transition is too slow, of course, but that was done to ensure you could see a transition in the gif. |
|
I'm not sure we've nailed it yet. I think it's better if transition authors don't need to concern themselves with whether or not the transition is supposed to run — even though they're composable it feels like the wrong place to be making that determination. I think it's also a little hard to grok — when I look at What if instead we could declare the 'scope' of a transition to be global (current behaviour) or 'local' (transition only applies when it's the parent block that has changed)? So perhaps we could introduce {#if visible}
{#each things as thing}
<div localtransition:fade></div>
{/each}
{/if}...the divs would only fade in or out as a result of (There's probably a better name for the directives but you get the idea.) |
|
@Rich-Harris would it make sense to follow suite with your thoughts on event modifiers here #1088 (comment) and use the pipe character? We could rename {#if visible}
{#each things as thing}
<div transition|localize:fade></div>
{/each}
{/if} |
|
#1734 uses pipes, but it puts them at the end (like events would) rather than in the binding name like I provided above. E.g. {#if visible}
{#each things as thing}
<div transition:fade|local></div>
{/each}
{/if} |
Allows transitions to skip running when they are added to the DOM or removed from it. Similar to the compiler option
skipIntroByDefaultthis allows the intro/outro to be skipped.Example:
{#if visible} {#each things as thing} <div transition:fade></div> {/each} {/if} <script> export default { transitions: { fade(node, params) { return { intro: false, outro: false, duration: 400, css: t => { return `opacity: ${t}`; } }; } } }; </script>In this example items in the each-block will fade in and fade out when they are added to or removed from
thingsbut the list will appear suddenly and disappear suddenly (no fade) whenvisibleis toggled totrueorfalse.This is another try at #1480 from the compiler option in #1692.