You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Imagine this:
You have a .svelte.js/ts file that exports some functions. In these functions, you want to pass a $state or $derived value and use it inside of an $effect, $derived, or something else where you want to keep the reactivity of the value; maybe you want to save the $state's value to a database or external resource as it updates, watch the value for changes and do something when it does change, etc. However, to do that, you have to put the $state value in a callback (or getter/setter object) in the parameters of the function. This feels rather clunky and un-Svelte like. Here's an example of what I mean.
Describe the proposed solution
While there aren't too many good solutions I've thought of, one that stood out to me was to make parameters that accept state values have a name prefixed with a $; the only problem I could see with this is that it may cause some confusion with stores. Examples: Before
After:
Some other solutions I've thought of, but don't feel would entirely fit Svelte include:
Making functions that use $stateful values have a $ prefixing their name
This makes it harder to have a function that takes $stateful values as a few parameters instead of all of its parameters.
This would basically make it possible to create new runes, which, in my opinion, kind of takes away some of the magic and simplicity of runes
Stating which values are meant to be $states using types
This just feels wrong if you are using vanilla JS. Using JSDoc (if you don't use TS) wouldn't feel good at all, not to mention it'd probably be difficult to implement in the compiler.
I disagree with this proposal. Feels like we’re adding new syntax for no reason other than to be convenient that ends up being confusing. The solution here is documentation if needed in my opinion. Your gripe seems to be with how JavaScript itself works not svelte. Primitives cannot be passed across boundaries magically. I see why people might find it inconvenient but I think this is an area where svelte should stay aligned with Js
Primitives cannot be passed across boundaries magically. I see why people might find it inconvenient but I think this is an area where svelte should stay aligned with Js
Svelte's runes turn primitives into an object to keep the reference and reactivity; I don't see why we'd have to work around the compiler to maintain that reference behavior.
Describe the problem
Imagine this:
You have a
.svelte.js/ts
file that exports some functions. In these functions, you want to pass a$state
or$derived
value and use it inside of an$effect
,$derived
, or something else where you want to keep the reactivity of the value; maybe you want to save the$state
's value to a database or external resource as it updates, watch the value for changes and do something when it does change, etc. However, to do that, you have to put the$state
value in a callback (or getter/setter object) in the parameters of the function. This feels rather clunky and un-Svelte like. Here's an example of what I mean.Describe the proposed solution
While there aren't too many good solutions I've thought of, one that stood out to me was to make parameters that accept state values have a name prefixed with a
$
; the only problem I could see with this is that it may cause some confusion with stores. Examples:Before
After:
Some other solutions I've thought of, but don't feel would entirely fit Svelte include:
$state
ful values have a$
prefixing their name$state
ful values as a few parameters instead of all of its parameters.$state
s using types$state
reactivity #11546 and Can we have specific types for reactive state in Svelte 5? #13267@ts-check
/@ts-ignore
(example)$state
for the default parameters (example:function foo(value=$state())
orfunction bar(value=$state)
Importance
would make my life easier
The text was updated successfully, but these errors were encountered: