* fix: make `defaultValue` work with spread
* chore: apply suggestions from review
* tweak
* only stash defaults when relevant
---------
Co-authored-by: Rich Harris <rich.harris@vercel.com>
* fix: avoid mutation validation for invalidate_inner_signals
* add test
* Update packages/svelte/src/internal/client/runtime.js
---------
Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>
fixes#14532
This removes the `reactive_declaration_non_reactive_property` warning altogether. The first version caused many false positives at compile time. The refined runtime version (introduced in #14192) was hoped to fix this, but it turns out we now get loads of false positives at runtime.
fixes#14391
In #13337 the "when to set as a property" logic for custom elements was adjusted. A bug was introduced during this, and it consists of several parts, of which the latter I'm not sure what's the best solution, hence opening this to discuss.
The problem is that during set_custom_element_data, get_setters is the only check done to differentiate between setting the value as a prop (has a setter) or as an attribute (doesn't have a setter).
The solution is to take into account whether or not the custom element is already registered, and defer getting (and caching) its setters until then. Instead, fall back to a "an object is always set as a prop" heuristic.
* chore: provide links to documentation for errors/warnings
closes#11305
* changeset
* fix most of the tests
* fix mutations messing with nodes between runs
* more concise
* more test fixes
* last one
* feat: add Spring class
* add some docs, Spring.of static method
* add Tween class
* lint
* preserveMomentum in milliseconds
* deprecate tweened
* changeset
* wrestle with types
* more consolidation
* flesh out the distinction a bit more, deprecate `subscribe`
---------
Co-authored-by: Simon Holthausen <simon.holthausen@vercel.com>
* chore: make if blocks dead code eliminable
* chore: make if blocks dead code eliminable
* chore: make if blocks dead code eliminable
* address feedback
* address feedback
* prettier
---------
Co-authored-by: Rich Harris <rich.harris@vercel.com>
When the `value` or `checked` attribute of an input or the contents of a textarea were static, setting the `defaulValue/defaultChecked` property caused the latter to take precedence over the former. This is due to how we transform the code: If the value is static, we put it onto
* tests
* typings
* implement for defaultValue/defaultChecked on inputs
* docs (draft)
* selected
* fix test
* remove
* tweak
* changeset
* untrack reads, they could be inside an effect
* Apply suggestions from code review
Co-authored-by: Rich Harris <rich.harris@vercel.com>
* handle select reset case
* handle reset case specifically: use different props/queries in that case
* enhance test
* fix
---------
Co-authored-by: Rich Harris <rich.harris@vercel.com>
* fix: better error messages for invalid HTML trees
closes#13331
* fix test
* more concise
* tweak
* tweak messages
* adjust tests
* tweak message slightly, so it doesn't sound like the bad element is the one we're currently encountering
* put locations in generated message
* tidy up
* consistency
* fix
---------
Co-authored-by: Rich Harris <rich.harris@vercel.com>
* add failing test for #14268
* simplify
* proxify values when using ||=, &&= and ??= assignment operators
* proxify values assigned to private state fields
* changeset
* fix
* fix
* add warning
* update test
* fix: don't try to add owners to non-`$state` class fields
`$state.raw` and `$derived(.by)` will not have a state symbol on them, potentially causing a disastrous amount of traversal to potentially not find any state symbol. So it's better to not traverse them.
Potentially someone could create a `$state` while creating `$state.raw` or inside a `$derived.by`, but that feels so much of an edge case that it doesn't warrant a perf hit for the common case.
Fixes#14491
* for bind:, too
* fix: ensure SvelteDate cached methods have no reactive context
* fix: ensure SvelteDate cached methods have no reactive context
* fix
* lint
* use active reaction at time of instance creation
* tweak changeset
* Update packages/svelte/src/internal/client/dom/elements/bindings/shared.js
Co-authored-by: Paolo Ricciuti <ricciutipaolo@gmail.com>
---------
Co-authored-by: Dominic Gannaway <dg@domgan.com>
Co-authored-by: Paolo Ricciuti <ricciutipaolo@gmail.com>
* turn `reactive_declaration_non_reactive_property` into a runtime warning
* ignore warning
* Update packages/svelte/src/internal/client/reactivity/effects.js
Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>
* Update packages/svelte/src/internal/client/runtime.js
Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>
* fix
* test
* changeset
* Update .changeset/witty-turtles-bake.md
Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>
* add some details
* check
* regenerate
---------
Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>
* Fix `$.update` and `$.update_pre` for bigints
* resolve conflicts
* fix some things
* fix thing i definitely didn't just break
* hopefully this will fix it
* fix formatting
* simplify
* style consistency
* simplify
* changeset
---------
Co-authored-by: Rich Harris <rich.harris@vercel.com>
* fix: upgrade to esm-env 1.2.1 to fix issues with non-Vite setups
* fix (albeit with annoying warnings)
* bundle with conditions to silence noise
* production is probably better
---------
Co-authored-by: Rich Harris <rich.harris@vercel.com>
fixes#14466
The logic introduced in #14395 was flawed - not every text or expression outside the template is the child of an attribute. This turns it around: We know that every child of a fragment is inside the template, so we ignore all text/expression tags that are not child of a fragment
Fixes#14399
Add a mechanism to connect render tags to snippets to know where to walk when coming across render tags
---------
Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>
Co-authored-by: Simon Holthausen <simon.holthausen@vercel.com>
fixes#14439
This bug was introduced in #13642 because setting the input to null means the equality check ("is the input different") fails if you set the value to null
Also fixes#14441 - this bug was present for a long time, and the reason is the same as for the other bug: The equality check always returns "yes this is the same" if the value is undefined initially. The fix is similar; we need to initialize the input to something that can never be equal to whatever value is passed
This reverts #13255 / #13158, and helps with the validation error part of #14120
If you would have a component like this...
```svelte
<td>hi there</td>
```
...and then render it on the server via our `render` function like this:
```js
const result = render(Main);
```
...then right now you get an error saying that `td` is not valid at this position. But that doesn't seem right, because we should give people the benefit of the doubt: It may very well be that someone renders such a component and then correctly puts it into a `tr` tag themselves on the server (another example is rendering a full html document like in #14120).
All the other validation where there's a known parent (X not valid inside Y) is untouched by this.
Doing this as cleanup prior to tackling #13331
* fix: always use set for private identifiers
* we can simplify this further - no need to check the value was transformed, since the outcome of not returning immediately is the same but with extra steps
* add explanatory note
---------
Co-authored-by: Rich Harris <rich.harris@vercel.com>
Yang Pan
Paolo Ricciuti
Rich Harris
Dominic Gannaway
github-actions[bot]
Simon H
grieben
ComputerGuy
Ben McCann
Theodor Steiner
Frédéric Crozatier