Skip to content
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

Closed
Rich-Harris opened this issue Mar 6, 2018 · 6 comments
Closed

Component outros #1211

Rich-Harris opened this issue Mar 6, 2018 · 6 comments

Comments

@Rich-Harris
Copy link
Member

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...

@jacwright
Copy link
Contributor

This is needed for fading a Modal out.

@Rich-Harris
Copy link
Member Author

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 intro: true, then we could avoid any weirdness with rehydrated markup. I guess that would be a breaking change though unless we were careful.

Probably need to think through the details a bit more deeply but this feels like a reasonable direction.

@jacwright
Copy link
Contributor

I think that is reasonable.

@Rich-Harris
Copy link
Member Author

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 <Widget> has outro transitions, and so setting foo to false should cause the if block to be outroed rather than unmounted. (This is another argument for whole-app optimisation — #1102).

As noted there, slotted content causes added complexity, though now that I've thought about it a bit I think it's manageable.

@jacwright
Copy link
Contributor

That would be amazing.

@Rich-Harris
Copy link
Member Author

As of 2.6, if you compile with nestedTransitions: true, components will be outroed instead of immediately yanked from the DOM.

In v3, nested transitions will become the default.

https://svelte.technology/repl?version=2.6.0&gist=a193bcaa34b3c458603818e006b2ab42

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants