* feat: make `<svelte:component>` unnecessary in runes mode
In Svelte 4, writing `<Component />` meant that the component instance is static. If you made the variable `Component` a reactive state variable and updated the component value, the component would not be reinstantiated with the new value - you had to use `<svelte:component>` for that. One reason was that having a dynamic component was more overhead, which is no longer the case in Svelte 5. We can therefore reduce the potential API surface area (by maybe deprecating `<svelte:component>` in the future) by allowing Svelte to recognize when a component variable is potentially dynamic. It turned out that this was already mostly the case. This PR fixes one case where it wasn't, and fixes another where this was wrongfully applied in legacy mode.
* we already have this function
* add interactive demos
* changeset
---------
Co-authored-by: Rich Harris <rich.harris@vercel.com>
Now that we've made `mount` and `hydrate` not call `flushSync` anymore, we can go back to using `queue_microtask` inside `#await`, which means people who want to synchronously see the pending block can do so using `flushSync` (as validated by our tests). This essentially reverts #12274
* chore: document `@html` and `<img src>` hydration change
Also add a test for it
closes#12333
* add a test
* Update sites/svelte-5-preview/src/routes/docs/content/03-appendix/02-breaking-changes.md
Co-authored-by: Rich Harris <rich.harris@vercel.com>
* lint
* update example and wording
* update test
* since it turns out we already had a test, we can delete the new one
* fix test
---------
Co-authored-by: Rich Harris <rich.harris@vercel.com>
* chore: reenable server CSS output through a compiler option
There are various use cases where this continues to be necessary/nice to have:
- rendering OG cards
- rendering emails
- basically anything where you use `render` manually and want to quickly stitch together the CSS without setting up an elaborate tooling chain
* cssRenderOnServer -> css: 'injected'
* update tests
* move append_styles into new module, update implementation
* get HMR working
* don't append styles to head when compiling as a custom element
* update changeset
* tweak
* tweak
* tweak wording
* update test
* fix
* reinstate optimisation, but without the bug
* fix sourcemap test
* move breaking change note
* Update packages/svelte/src/internal/server/index.js
Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>
---------
Co-authored-by: Simon Holthausen <simon.holthausen@vercel.com>
Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>
* breaking: play transitions on `mount` by default
closes#11280
* only prevent transitions when the component is invalidated
---------
Co-authored-by: Rich Harris <rich.harris@vercel.com>
Fixes#12166. Turns out that the recent refactors here negated the fact that non-runes mode uses a slightly different source signal that has different equality rules.
I also updated the docs in this PR too to reflect that only plain objects and arrays are proxied.
better examples
---------
Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>
Co-authored-by: Simon Holthausen <simon.holthausen@vercel.com>
* docs: make legacy.componentApi more visible
People didn't know that this exists, so we should make it more visible through having it be part of the error message, and calling it out in the docs with more details
* clarify
* flesh out message, put error behind a function
* make it work with HMR
* fix
* fix
* this makes it work. i don't fully understand why
* changeset
* changeset
* Delete .changeset/twelve-foxes-press.md
---------
Co-authored-by: Rich Harris <rich.harris@vercel.com>
- clarify that a callback prop means passing a function
- enhance the example so that a parameter is passed and the prop is explicitly invoked to visualize the concept better
closes#11671
In Svelte 3 and 4, components were classes under the hood, and the base class was `SvelteComponent`. This class was also used in language tools to properly type check the template code.
In Svelte 5, components are functions. To give people a way to extend them programmatically, it would be good to expose the actual shape of components. This is why this PR introduces a new `Component` type.
For backwards compatibility reasons, we can't just get rid of the old class-based types. We also need to ensure that language tools can work with both the new and old types: There are many libraries out there that provide `d.ts` files with type definitions written using the class types - these should not error.
That's why there's an accompagning language tools PR (https://github.com/sveltejs/language-tools/pull/2380) that's doing the heavy lifting: Instead of generating classes, it now generates a constant and an interfaces and uses Typescript's declaration merging feature to provide both so we can declare a component export as being both a class and a function. That ensures that people can still instantiate them with `new` (which they can do if they use the `legacy.componentApi` compiler option), and it also ensure we don't need to adjust any other code generation mechanisms in language tools yet - from a language tools perspective, classes are still the norm. But through exposing the default export as being _also_ callable as a function we can in a future Svelte version, where classes/the Svelte 4 syntax are removed completely, seamlessly switch over to using functions in the code generation, too, and the `d.ts` files generated up until that point will support it because of the dual shape. This way we have both backwards and forwards compatibility.
Simon H
Rich Harris
Dominic Gannaway
Cevdet Arda Haran
Kohei Yoshino
Willow (GHOST)
Paolo Ricciuti
Dominik G
Ahmad S
Theodor Steiner
Ben McCann
Dillon Mulroy
Marcos Rigoli
Sharath Kumar