- run reactive statements only once per tick, even when they have indirect cyclic dependencies. Made possible by adding an array to the component context, which is filled with identifiers of the reactive statements, and which is cleared after all have run. Reactive statements rerunning before that will bail early if they detect they're still in the list
- part of the solution is to run all reactive statements, and then all render effects, which also fixes#10597
* fix: improve bind:this support around proxyied state
* fix: improve bind:this support around proxyied state
* fix: improve bind:this support around proxyied state
A handful of minor cleanups:
- there were two different "do this" / "don't do this" formats. Standardize on the one that's much easier to read
- clarify that callback props are being used (component events no longer exist in Svelte 5)
- rename variable from `proxy` to `facade` since it's not a proxy
Get more validation tests passing:
- const tag cyclic validation (now runtime, based because of new reactivity system)
- illegal-variable-declaration
- illegal-attribute-character
- remove invalid-reactive-var validation as legacy reactive statements are transformed to functions under the hood, which never escape scope - arguably not completely correct, but will be what the user expects anyway
- invalid-rest-eachblock-binding
- remove edge-case redundant-event-modifier warning because event modifiers are deprecated anyway
- invalid-style-directive-modifier
- invalid-tag-property (now a different error)
- module-script-reactive-declaration
- take comment above script into account when silencing warnings
- invalid-css-declaration
- unused-export-let
- invalid-html-attribute
- illegal-store-subscription
- empty-block
- use interface instead of type (interface is less forgiving)
- rename SourceSignal to Source, etc
- make Derived extend Source, rather than deriveds sharing a type with effects, since they have much more in common with each other
- have a Value type which is a union of Source and Derived, and a Reaction type which is a union of Derived and Effect
- avoid using the Signal type (which is a union of all three) unless necessary
* move some code
* split computations.js into deriveds.js and effects.js
* move reactivity types into separate .d.ts file
* move some signal code
---------
Co-authored-by: Rich Harris <rich.harris@vercel.com>
* fix: treat snippets like normal components when inferring namespace
* n
* simplify
* better desc
* slight adjustment
* feedback
Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>
* feedback
Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>
* skip html tag
* test
* changeset name
* cleanup
---------
Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>
Checking for expected or unexpected props in 2024 is the job TypeScript, and runtime validation has resulted in false positives previously - therefore leave this out in Svelte 5.
closes#10672
- explain when not to use `$effect`, closes#10193
- explain that only synchronous reads are tracked, closes#10475
- explain nuance around reruns and object reads, closes#10392
- widen ownership when getContext is called, part of #10649
- widen ownership when assigning one proxy to another
- skip first 4 stack trace entries and bail if first after that is not a module, hinting at a mutation encapsulated in a .svelte.js file; part of #10649
* feat: improve ssr html mismatch validation
* update types
* Update packages/svelte/src/internal/server/index.js
Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>
* Update packages/svelte/src/compiler/validate-options.js
Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>
* feedback
---------
Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>
This has a lot of overhead for large lists, and we can at least diminish in the "no state proxy" case by applying a sensible heuristic:
- If the value passed is a state proxy, read it
- If not, and if the value is an array, then bail because an array of state proxies is highly unlikely
- Traverse the first level of properties of the object and look if these are state, if not bail. State proxies nested further down are highly unlikely, too
part of #10637
It's a warning because even when typing it out and knowing what to do you'll always be in a state where the validation kicks in, and it would be too distracting to always see a compiler error during that short time frame.
closes#10374
People could've done bind:this and called instance methods on the instance - a rare case, but not impossible. This shims $set and $on when in legacy compat mode. $destroy is never shimmed because you shouldn't manually destroy a component, ever, and there's no way to make that work in the new world.
closes#10420
Dathan
Simon H
github-actions[bot]
Dominic Gannaway
Papaya
Ben McCann
Rich Harris
Ahmad