Honoring reassignment of state instead of mutation

[noahw3]

One of the big gotchas that I've run into several times with Valtio is that you must deeply mutate the state in order to guarantee compatibility with all useSnapshot use cases. If a snapshot was taken of a slice of the proxy state, and that proxy state is reassigned instead of mutated, any observers on that state break.

One of the major benefits of the mutable state model is that it is, in theory, easier to update state than with an immutable model because you don't have to ensure that new references are created. However, currently Valtio has the opposite problem where extra care has to be taken to ensure the new references are never created. This is particularly clunky when you do want to entirely replace a chunk of complex state - it requires first mutating the state back to some default version, and then mutating it with the new values.

It's not hard to find examples where people have run into this issue:
#525
#76
#241
#875

I also created a codesandbox to illustrate some of these possible cases: https://codesandbox.io/p/devbox/dsh49s
In an ideal world, all of these cases would work. The case with reassignment but then also mutating the old state seems particularly unintuitive.

I wonder if this is something that could be considered as part of v2? It would indeed be a breaking change, but also seems like it would address one of the big pain points and sources of confusion with Valtio.

[dai-shi]

Hi, thanks for opening a discussion.
If I understand your request correctly, it's technically impossible.

In an ideal world, all of these cases would work. The case with reassignment but then also mutating the old state seems particularly unintuitive.

It seems to me that it's a doc issue. We should basically use the root state.

-   const users = useSnapshot(state.users);
+   const { users } = useSnapshot(state);

That way, it works intuitively, no?

[noahw3]

One of the use cases that I was thinking about was if you're attempting to take snapshots of deeply nested state. On the surface it seems like a reasonable pattern to peel off the layers of the proxy from the root and pass them down to children, with the child taking snapshots of those and being oblivious to the root. However, I realized that even if Valtio replaced the listeners this pattern would still be an issue; in these nested children you'd be holding onto a reference to the old proxy, even if upstream it was replaced. So this is probably an anti-pattern in the first place.

As long as you're always snapshotting from the root, that approach should work. Do you think that's a blanket statement that should be made? That it's recommended to only snapshot the root state, and then have all property access off of that? If that's the case then yeah that should probably be added to the documentation. I'm also wondering if it'd be possible to add a lint rule to forbid snapshots with nested access.

[dai-shi]

In case, we miss something, here's the mental model:

const users1 = useSnapshot(state.users);
// that 👆 is like this 👇 
const users1 = deepCopyAndDeepFreeze(state.users);

// when you reassign users property
state.users = { someUser: {} };
// users1 shouldn't be the same as state.users
isDeepEqual(users1, state.users) === false

Do you think that's a blanket statement that should be made?

I wouldn't recommend it blindly because there is a benefit of scoped subscription (which I assume an advanced usage), but for beginners, we can generally recommend that pattern.