Svelte 5: deprecate <svelte:component>

[Rich-Harris]

Describe the problem

See #12646 — we're now in a position to deprecate <svelte:component> if we want.

There are some places where in theory it still makes sense to keep it:

<script>
  import A from './A.svelte';
  import B from './B.svelte';

  let { condition } = $props();
</script>

<svelte:component this={condition ? A : B} />

{#each things as thing}
  <svelte:component this={thing.component} />
{/each}

We could solve these with $derived or @const but maybe that's not as nice. The second one could be solved by treating <thing.component> as a component rather than as an (impossible) element, which is a change we could make separately or at the same time. (It would conflict with Svelte Native's property elements, however.)

Both should be considered for 5.0

Describe the proposed solution

see above

Importance

nice to have

[Conduitry]

My unscientific impression is that nearly all uses in the wild of <svelte:component> could be simply represented as a dynamic <Component/> without fiddling around with $derived or @const. And that not having two ways to do this outweighs the slightly more verbose code that would be required without it.

The this={} is also just really nasty and I don't like it. I'm also thinking, though, about #12662 (which is about <svelte:element>) where there is a desire to let this be spread to like any other attribute. I don't know whether that's something we want to let people to do (it still seems gross to me) (and I'm doubting that works today with <svelte:component> either) - but whether we get rid of <svelte:component> seems also somewhat tied to the question of whether we want people to be spreading to this. If we don't, it's better to get rid of the syntax entirely that tempts people to try to write code that way.

[paoloricciuti]

The second one could be solved by treating <thing.component> as a component rather than as an (impossible) element, which is a change we could make separately or at the same time. (It would conflict with Svelte Native's property elements, however.)

This could be solved by documentation because it already works if you use Thing instead of thing

REPL

And to be fair it seems like a better solution considering also the other components needs to be Uppercase

Tbf it would be cool to have a solution for the first tho even if the derived solution is still not bad.

[rChaoz]

On a side note: I think the docs stating <svelte: component> is no longer needed for dynamic components should be moved to deprecations from breaking changes

[Rich-Harris]

It is a breaking change — <Thing> didn't update when Thing changed, and now it does. So it's in the right place

[Conduitry]

We could still reword it, though - the main thing for the breaking change is that the behavior of <Thing> is different, not that <svelte:component> is no longer necessary, which does indeed sound more like something for the deprecation section.

[paoloricciuti]

Actually now that I think about it it would be good to throw a warning if you are trying to use thing.something as the name of a component suggesting to uppercase thing...I'll try to work on this this evening (both the deprecation and the warning)

[Rich-Harris]

We'd need to make sure that thing is in scope, otherwise we'd be throwing Svelte Native users under the bus

[paoloricciuti]

We'd need to make sure that thing is in scope, otherwise we'd be throwing Svelte Native users under the bus

Yeah only if it has a binding

[craigcosmo]

hey guys, I got a bunch of these warnings, how do I know which part of my code is causing this warning ? and what should be the easier solution to fix?

[paoloricciuti]

hey guys, I got a bunch of these warnings, how do I know which part of my code is causing this warning ? and what should be the easier solution to fix?

This is from the sveltekit generated root. There's already a PR open to fix this sveltejs/kit#12584 so when that pr is merged they will go away when you update svelte kit