* chore: perf tweaks for actions/styles/classes
- check if we really need to add/remove the class (calling `includes` first is cheaper than always setting/removing it)
- check if we really need to update a style (calling `getPropertyValue/setProperty` is expensive)
- check if we should call the action's update function (this is not only a perf tweak but also a correctness fix)
closes#12652
* changeset
---------
Co-authored-by: Rich Harris <rich.harris@vercel.com>
* start moving visitors into separate modules
* remove unused code
* more
* more
* tidy up
* more
* more
* more
* more
* more
* more
* more
* more
* more
* more
* more
* alphabetize
* more
* fix
* more
* more
* consolidate
* more
* more
* more
* more
* more
* more
* more
* tweak
* more
* more
* more
* more
* more
* more
* more
* more
* more
* more
* jfc what are we doing here
* more
* bizarre
* more
* more
* more
* more
* more
* more
* tidy
* one down
* dont merge
* hmm
* DRY
* more
* more
* tidy up
* tidy up
* add changeset, as this should have its own release
* tidy up
* oh i should probably hit save
* 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>
language tools has to type its own shape for backwards compatibility, and it currently doesn't include the `$on` and `$set` methods, which means without widening the type as done here you would get a "this shape is not accepted" type error when passing it to `ComponentProps`
closes#12627
Adds a compiler warning that warns about legacy component instantiation (i.e. using `new Component(..)`). This won't catch all cases, but the most obvious ones which probably make up ~80%
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
Closes#12643
Very weird behaviour from the draggable setter...if you set element.draggable="false" it will actually set draggable to true (the boolean).
* chore: tweak html tree validation
- relax validation in some places where we know the HTML will not break or only break when using SSR
- consolidate validation in one place and for better reuse, which results in more cases getting caught at runtime
closes#11941
* move more of the validation into more descriptive record
* obselete / incorrect (those are not autoclosed, and the invalid ones handled later)
* typo
* backticks
* update tests
* Update packages/svelte/messages/compile-errors/template.md
Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>
* Update packages/svelte/messages/compile-warnings/template.md
Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>
---------
Co-authored-by: Rich Harris <rich.harris@vercel.com>
* better code generation for slot props in SSR
* simplify
* remove getters mechanism from server compiler
* changeset
* no need to use getters in SSR mode
* fix comment
* start modularizing server code
* more
* more
* more
* more
* alphabetize
* start on JS visitors
* more
* more
* more
* more
* less
* more
* alphabetize
* lint
* combine into single visitors folder
* alphabetize