Creating Sub-stores / MVVM Pattern (Please critique!)

[CodeSmith32]

Project / Concept:

I've been considering Zustand as a possible candidate for implementing ViewModels. When it comes to more complex applications, one of the struggles is maintaining a tree of state for a tree of components, but in one place.

Example App:

 

Component Tree vs. State Tree:

 

In this example, I have an item list that can grow and shrink in size. Each of those item components needs to have state. A naive approach could be to pass each component an initial state, and let the component take over control of the state. But this has obvious drawbacks, like not being able to read or update the child's state from parent components. However, such an approach is common, because it can get very complicated to pass a tree of state downwards, especially when the component + state tree is deep, or there are lists within lists.

The MVVM pattern encourages fully separating the state from the UI. A ViewModel connects the server (where true model is stored) to the UI, providing state updates when the model changes, and receiving and dispatching model updates from UI events. When I first considered implementing such a ViewModel, I immediately thought of Zustand because it makes this separation pretty intuitive. But the one thing Zustand lacks is the innate ability to create 'sub-trees' of states.

In this project, I aimed to fill that gap by implementing a sliceStore method which takes a Zustand store and generates a 'sub' store - essentially, a virtual slice of the parent store. A sub-store has a getter and setter that interacts virtually with one piece of the parent store. Internally, though, the getter extracts from the parent store, and the setter updates it. The specific get / set logic must be implemented by the developer for each sub-store. The getter must extract the child's state from the parent, and the setter must update it.

Here's my example of this sub-store system. The top image above shows a picture of the simple app, and the one below illustrates the three levels of stores - the root Zustand store, the ListItem stores, and the Tag stores.

To demonstrate its effectiveness, I included an 'Add Tag to All' button to show that updating child state from the parent works seamlessly. Furthermore, I memo'ed the list and tag components to show that, with this small memo optimization, only the components that use changing state will re-render on state updates. To see this effect, turn on debug mode. (As a note, the memo is required because the list component always re-renders since it depends on the list of children, which always changes if any child changes. But this is much better than re-rendering every component in the entire tree.)

---

Afterthought / Feedback

With that said, I'm really looking for good critique on this appproach. Here are some of my questions:

1. Is it a good approach in general? i.e., Does it solve real problems? Or are there simpler solutions?
2. Do I understand MVVM correctly? Or am I doing it poor injustice? 😃
3. Am I overlooking any major pitfalls with this approach?
4. Are there additional improvements that could be made?
5. Anything else you wish to add..

Thanks!

[CodeSmith32]

Ok, I did some deep thinking, and came up with - I think - a much better approach.

I hate to say it, but I did end up kicking out Zustand with this approach. With that said, it's pretty incredible, and makes state management as easy as mutating plain JSON in Javascript. It uses a tree of proxies, tracks 'get' requests while rendering, and triggers re-renders when 'set' is triggered in the proxies.

The only requirement is to wrap functional components that use state with a new reactive function, similar to React's memo or forwardRef functions.

I re-implemented the same app as before using the new system.

As you'll see, modifying state is as easy as pushing / splicing arrays, assigning properties to objects, etc. Components using state will automatically react to changes they use, and nothing else. Another win is that modifying data deep in the state tree doesn't require replacing all objects/arrays up to the top-level. The object values remain stable, but reactivity still works seamlessly!