Fixes#11817.
It turns out that we weren't fully handling the disconnection of derived signals from the reactivity graph – resulting in cases where they could leak memory because they were not being removed from their dependency reactions array. However, removing ourselves from this array meant that any future changes might mean we need to reconnect the derived to the graph again – so we have to do some additional bookkeeping to make this work. Thankfully, we already have versioning because of unowned deriveds, we can use the versions to understand if the owned derived signal is dirty after being connected to the reactivity graph again – something we couldn't do in early permutations of the signal architecture – and likely why we hadn't addressed this in the same sense.
If a property is mutated, the assumption is that it is deeply reactive. In those cases, the fallback value should be proxified so that it also is deeply reactive.
fixes#11425
- the previous assumption was wrong: browser don't fire a scroll event initially when the scroll isn't smooth
- the previous logic wasn't using the "is scrolling now" logic which meant the render effect fired immediately after, causing smooth scrolling to start too late to be overridden
adjusted the comment and reused the scroll handler function to guard against the race condition
fixes#11623
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.
* breaking: disallow string literal values in `<svelte:element this="...">`
* note breaking change
* Update sites/svelte-5-preview/src/routes/docs/content/03-appendix/02-breaking-changes.md
Co-authored-by: Jeremiasz Major <jrh.mjr@gmail.com>
* prettier
* make invalid `<svelte:element this>` a warning instead of an error (#11641)
* make it a warning instead of an error
* format
---------
Co-authored-by: Jeremiasz Major <jrh.mjr@gmail.com>
In the case of an invalid child element, we already get information about the parent and the child, but in other cases where a mismatch could occur you're pretty much on your own.
This adds a bit more context to hydration_mismatch warnings — 'The error occurred near ...'
* feat: add rootDir option and set __svelte_meta.file like in svelte4
* Update packages/svelte/src/compiler/validate-options.js
* update tests
* centralise logic
* fix
* note to self
* Apply suggestions from code review
* lint
* one dollar towards the windows backslash bugfix foundation please
---------
Co-authored-by: Rich Harris <rich.harris@vercel.com>
Co-authored-by: Simon Holthausen <simon.holthausen@vercel.com>
Dominic Gannaway
Paolo Ricciuti
Simon H
github-actions[bot]
Rich Harris
FoHoOV
Dominik G