Should States be Compiled As An Object Property?

[CarsonGH]

I believe that many of the problems I have came across are due to states being compiled directly as objects instead of a top level object with the state as the property. ( DISCLAIMER: I do not deeply understand the svelte source code so I don't know if this is actually how the compiler works)

The problems that I encounter are that states passed through imports or contexts cannot properly view the top level value so:

myState = getContext("state")
console.log(myState)  <- this will only return the initial value and never an updated value

Because objects cannot have functions as their getters we cannot properly pass svelte state through context or imports as the top level value will always be wrong/not update. Instead are only able to access properties as the getters of these are functions which correctly get the values.

If the compiler instead made all instances of the state into an object with the state value as a property this would allow states to work as context objects and as imported objects.

Now I have no idea of how much of a performance impact or how breaking a change like this would be to the project overall. But to me it seems like this is the only way for states to work properly and as expected.

Here is a repl which shows how context doesnt share value properly REPL

To me this seems like svelte should handle state updating in this manner. The point of svelte is to make frontend development just feel like regular javascript and updating objects directly just works, but currently this is one spot where it doesn't work as expected.

(EDIT: I have now read that svelte is using proxies for intercepting the actions of the get, but the same logic still applies as proxies are not allowed to intercept the get of the top level object also)

[brunnerh]

Because objects cannot have functions as there getters

They can? I also showed this in an example in your recent question.

let value = $state(null);
setContext('context', { get value() { return value; } });
// or if you just want to read a value, pass a function:
setContext('context', () => value);

[CarsonGH]

I don't believe you did. You just returned a getter function associated with the state but you did not change the underlying getter of the top level object. This is impossible in javascript. It's why in solid you access states as functions if I'm not mistaken?

[brunnerh]

See the last example of this comment. Whether the object is passed to some arbitrary function or setContext does not matter, the principles around reactivity are the same.

Variables do not have a getter at all and you don't need to change anything about the variable, in Svelte it's about how and when you access the variable.

Solid exposes signal objects directly. Signals can either be implemented with functions or with getters/setters.

[CarsonGH]

I understand that, what I am saying is there would be a way to make it so both setters and getters of a top level object work with svelte reactivity. Remeber svelte is NOT javascript and thus svelte files can have different characteristics compared to basic javascript. So although variables do not have getters by making them properties of a top level variable we can actually make it so they DO have getters and setters.

If we compiled the javascript such that all states were properties of top level objects then it would be possible to directly update single value states even when passed through contexts or imports. This would make states behave more like true let objects which I believe is the whole goal of svelte specifically svelte 5 states.

Svelte is trying to improve upon the javascript ecosystem and make it simple to update objects without having to change the structure, or create a function that wraps an object, or pass an anonymous getter instead of the underlying object.

I am saying that svelte could allow signals to behave like regular objects and not require function invocation while still allowing for full reactivity through contexts and imports.

I believe that this would solve the underlying cause of this issue aswell.

[CarsonGH]

#9237 This issue mentions the same problem and it got marked as not planned until further usage of svelte.

I wish this was mentioned more clearly in the docs though because it doesn't cause issues often but when it does you have to understand the underlying signal object to figure out why it's not working as expected. which is quite unintuitive especially for beginners.

It does say this in the docs Only plain objects and arrays are made deeply reactive by wrapping them with Proxies: but I am honestly not quite sure if that explains this?

I think if it were made more clear in the documentation about the limitations of $state variables specifically in regards to not being able to use single level variable based states in context or import scenarios would be good if this is a design choice of svelte as a whole.

[brunnerh]

It's mentioned here a bit: https://svelte-5-preview.vercel.app/docs/universal-reactivity

The note on deep reactivity and proxies mostly contrasts the behavior with classes, which do not become deeply reactive by putting them in a $state.