* chore: make DOM operations lazyily init
* cleanup types
* cleanup types
* cleanup types
* Update packages/svelte/src/internal/client/operations.js
Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>
* single line annotations
* remove unnecessary coercion
* group statements by type
---------
Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>
Co-authored-by: Rich Harris <rich.harris@vercel.com>
* fix: address bug in before/after update
fix: address bug in before/after update
* Add changeset
* use every instead of filter - more explicit and enables early-exit from the loop
* Update logic and comment
---------
Co-authored-by: Rich Harris <rich.harris@vercel.com>
- add event delegation to spread_attributes
- add event attributes to spread
- don't delegate when bindings/actions on the same element in order to preserve backwards compatibility of ordering
- don't hoist identifiers when one of them is used in an event that is not delegateable
---------
Co-authored-by: Simon Holthausen <simon.holthausen@vercel.com>
no two-way binding because setting it involves a `DataTransfer` workaround, so it's not really officially supported that way - if you need that, you shouldn't use that binding probably. This matches the behavior in Svelte 4.
Co-authored-by: Rich Harris <rich.harris@vercel.com>
I came to the conclusion that when we're making up arbitrary types, we might as well keep the old class. That way:
- one less thing to worry about (language tools and other tooling basically can continue to spit out SvelteComponent )
- we can more clearly mark $set , the constructor etc as being deprecated and no longer functioning unless you use that legacy compatibility mode
- much more ergonomic to type for the user:
- const someInstance: SvelteComponent<..> instead of const someInstance: ReturnType<typeof Component<..>>
- If you're using generics, you can do export class MyComponent<T> extends SvelteComponent<{ prop: T }> {} instead of having to type out the whole function in a way that I'm not even sure how to do with generics
* lets see if this works
* fix versions
* sigh
* debugging ci is sooo fun
* oh wow
* fix stuff, changelog, add back readme
* appease prettier
* format stuff
related to issue #9088
it doesn't solve the main problem of dependencies getting invalidated whenever value of a variable gets changed.
but it fixes the behavior difference between the code with and without comments
fixes#9092
---------
Co-authored-by: gtmnayan <50981692+gtm-nayan@users.noreply.github.com>
Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>
fixes#9185.
I narrowed down the issue to the bug surfacing when we use object properties to update style attributes and directives. This fix removes the size check (because a single object will be of size 1 but can affect n attributes/directives via its properties).
In addition, the order of the OR is switched as the earlier condition has some reactive assignments which are not run in the current order when style_changed_var is truthy.
github-actions[bot]
Dominic Gannaway
Simon H
Yuichiro Yamashita
Rich Harris
Paolo Ricciuti
gtmnayan
Simon Holthausen
Kelvin Soh
Ben McCann
Sina Salahshour
vhladko
Teo
paulreece