-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Component outros #1211
Comments
This is needed for fading a Modal out. |
I think we can tackle this by adding component versions of the transition directives: {#if visible}
<!-- this component might have intro transitions, if so they will run -->
<Widget in:true/>
<!-- this component might have outro transitions, if so they will run -->
<Widget out:true/>
<!-- this component might have either -->
<Widget transition:true/>
{/if} The presence of these directives would cause the parent component to include the transition manager code, without the parent needing to know any of the specifics of the child's transitions. This could also solve another problem, #547. If the default was for top-level intro transitions not to run, unless the component had been instantiated with Probably need to think through the details a bit more deeply but this feels like a reasonable direction. |
I think that is reasonable. |
Update on this: I proposed here that we should actually make outroing components the default, because it's part of the solution to a larger problem of dealing with nested transitions. In other words, this... {#if foo}
<Widget/>
{/if} ...would be compiled with the assumption that As noted there, slotted content causes added complexity, though now that I've thought about it a bit I think it's manageable. |
That would be amazing. |
As of 2.6, if you compile with In v3, nested transitions will become the default. https://svelte.technology/repl?version=2.6.0&gist=a193bcaa34b3c458603818e006b2ab42 |
Creating a separate issue from #1210 (comment) so we don't lose it.
When components are destroyed, top-level outros don't run. Maybe that doesn't need to be the case for nested components.
Maybe it doesn't need to be the case for top-level components either, though we'd need a new public API to handle those cases...
The text was updated successfully, but these errors were encountered: