Component lifecycle inside <slot>

[ekhaled]

Components inside <slot> are created once, and never destroyed until the main parent component is destroyed.
Even when wrapped in {{#if}} blocks.

Additionally, they are created regardless of whether the guarding {{#if}} condition is true or false

Here is the REPL: https://svelte.technology/repl?version=1.41.1&gist=5234dc5ba4ee472d47b03e55e2ee53bb

Please open the console when you get there.

In the REPL, Alan gets created and destroyed as expected, but Mike sticks around
(Mike and Alan will make sense when you look at the REPL 😄 )

[Rich-Harris]

Yeah, this is expected behaviour. Basically, there's no way for the parent component to know whether or not the child's <slot> is inside an if block or not — all it can is say 'here is your content, do with it what you will'.

[ekhaled]

is it something that could be fixed in the future?

The main downside of this I find (apart from memory usage), is consistency.

Maybe in the future when we have a central tree of components to support HMR etc. this will start behaving as normal.

Closing

[EmilTholin]

Sorry for bumping this closed issue. I only have a surface level understanding of the Svelte codebase, so I just thought I'd ask if this is even possible to implement? I ask because I was silly and didn't test this thoroughly before I settled on an API for my routing components.

[Rich-Harris]

I'll reopen this issue for now, pending an eventual better-thought-out reply. I think it might be possible — in fact it kinda worked this way when <slot> was still {{yield}} — but it creates some headaches.

It's supposed to work like <slot> does in web components — if you have something like this...

<custom-element>
  <div slot='foo'>this div always exists, even if there's no corresponding &lt;slot&gt;</div>
</custom-element>

...then the custom element has no control over the shadow DOM, beyond adding/removing the <slot> element.

[force1267]

I was playing with svelte on this little project, neat and had this serious issue.
I think the way slot is handled now is not normal
another example at repl

[ChrisTalman]

It's nice being able to use <slot> to create 'wrapper' components, like this. In doing so, the 'wrapped' component can easily have properties passed directly to it and have various directives declared upon it.

However, as this issue suggests, the extraneous singular creation of <slot> components significantly limits the capabilities of wrapper components.

There are at least two alternative approaches, but they're not as elegant as wrapper components.

To start with, logic could be declared directly within the <slot> content itself, but this typically violates the DRY principle, besides revealing complexity which could otherwise be hidden internally within the wrapper component logic.

Alternatively, a wrapper component could not use a <slot> at all, and instead require a component to be passed to it, which is then passed as a dynamic component. However, this then makes it awkward to pass properties to the wrapped component and declare directives.

I'm not sure how the technical difficulties which have been discussed in this issue could be overcome, though. I would note that, if instant <slot> component creation is desired in some circumstances, it might perhaps be possible for a wrapper component to somehow declare whether or not its contents should be created instantly or not. That way, the developer could choose which behaviour they desire in any particular situation.

As an aside, I've just seen #1648 and it seems to be about the same topic.

[Rich-Harris]

I'm going to close this, as the behaviour of slots in v3 is essentially what's being discussed here — they are created lazily, whenever the child component needs them. It's a departure from the semantics of <slot> on the web normally, but experience has shown us that those semantics don't really make much sense if you can avoid them.