- 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
* november draft
* Apply suggestions from code review
Co-authored-by: Ben McCann <322311+benmccann@users.noreply.github.com>
Co-authored-by: Stanislav Khromov <stanislav.khromov+github@gmail.com>
* add version number to kit suggestion
* add svelte summit blurb
* update title, move summit to intro, add deno note
* Update documentation/blog/2023-11-01-whats-new-in-svelte-november-2023.md
Co-authored-by: Ben McCann <322311+benmccann@users.noreply.github.com>
---------
Co-authored-by: Ben McCann <322311+benmccann@users.noreply.github.com>
Co-authored-by: Stanislav Khromov <stanislav.khromov+github@gmail.com>
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