-
-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Svelte 5: Allow classes to opt-in to deep reactivity #11846
Comments
Is |
It is under my control. Is there a better alternative I'm missing? |
I guess the question then is, whether there is a reason not to make the fields of the class stateful? Given the example thing: class Thing {
- foo: number;
+ foo = $state<number>();
- bar: string;
+ bar = $state<string>();
} (Would need assertions if you want to prevent |
The reason not to go that route is that One might say this is a userland problem and could be solved pretty robustly with a simple helper. Something like: let reactiveObj = $state(deeplyMakeStateful(plainObj)) where And that does work, but now we're walking the object tree twice (worse performance) and adding boilerplate (unintuitive) wherever |
Describe the problem
I understand the rationale for
$state
not proxying non-POJO objects, but I think having non-POJO reactive state is a very useful pattern that is worth trying to support.A very simple example (and my current use case): Part of state is a
Grid
which wraps a 2d array and provides helper methods likegrid.at(coord: Coord)
. By forcing state to be only POJO, I now have to do one of:grid[coord.row]?.[coord.col]
throughout the appGrid.at(grid, coord)
There are loads of example use-cases like this, as it's a pretty common data modeling pattern (usually a
Model
pattern is just "some raw data + some helper methods to access/modify the raw data").Describe the proposed solution
For the sake of nomenclature, let's just refer to classes and class instances, though of course classes aren't the only way to create objects with a non-
Object
prototype.It would be nice to allow classes to opt in to being "proxy-able", either by specifying that the proxy should wrap the entire object, or by specifying some subset of fields to be proxied.
A potential syntax: (exact naming TBD)
Then, when proxy checks whether to wrap the object, it can also check
prototype[$state.proxyable]
and proceed accordingly.Option 1 downsides: Users may hit errors resulting from private/internal property accesses, arguably making
$state
a slightly leakier abstraction than it currently is.Option 2 downsides: The list of proxied fields would also have to be stored in the metadata and queried during various proxy traps, which is less than ideal from a performance perspective.
Importance
nice to have
The text was updated successfully, but these errors were encountered: