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.
---------
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>
Make IntrinsicElements extends SvelteHTMLElements
so it can be extend with declare module
converting to module so it can extend without needing another type alias
---------
Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>
Fixes#2943
The issue linked above invalidates a variable that is not defined in <script> but instead is defined as a let: variable, which does not make sense to invalidate, therefore, this PR exists.
In dev mode, Svelte creates a setter to throw an error noting that you can't set that readonly prop, which resulted in the accessor getting applied twice to the custom element wrapper, causing an error
fixes#8971
This should help everyone who has special needs and use cases around custom elements. Since Svelte components are wrapped and only run on connectedCallback, it makes sense to expose the custom element class for modification before that.
- fixes#8954 / closes#8955 - use extend to attach the function manually and save possible values to a prop
- closes#8473 / closes#4168 - use extend to set the proper static attribute and then call attachInternals in the constructor
- closes#8472 - use extend to attach anything custom you need
- closes#3091 - pass `this` to a prop of your choice and use it inside your component
- add some doc for #8987