Replies: 2 comments 2 replies
-
Not quite. Svelte 3/4 work via invalidation on any assignment involving a state variable. viewModel.name = 'new name'; All of that code would need a mutable state source or be rewritten to an immutable style like: viewModel = { ...viewModel, name: 'new name' }; So I do not think this change would make sense, it would probably just cause more boilerplate as people would reach for the mutable version. |
Beta Was this translation helpful? Give feedback.
-
That would also freeze the object with It feels like something that should not be a default to me too or at least be documented better (unless I missed it). |
Beta Was this translation helpful? Give feedback.
-
(Sorry if this is a duplicate but I couldn't find a related discussion)
In my opinion switching to $state.frozen as the default makes a lot of sense for a few reasons:
Keeps Things Familiar: It’s pretty much how Svelte 3/4 handled object updates, so it wouldn’t be a big leap for anyone already used to that style.
Performance: as described in the docs, the object doesn't need to be made reactive so by default it is the more performant option (correct me if I am wrong)
Easier Comparisons: Since frozen state is immutable, we don't need to use the $state.is rune to compare
What do you think about it?
Beta Was this translation helpful? Give feedback.
All reactions