Heavy Redux user here, why should I migrate to Zustand?

[binarykitchen]

Hallo Leute (= folks)

(Zustand is German, and I speak German too. Are the Zustand inventors Germans?)

Anyway, I'm planning to refactor the (Videomail-Client)[https://https://github.com/binarykitchen/videomail-client] to use either Redux or Zustand. I just can't decide. Hence, the discussion here ...

I come from a Clojure world and totally like (re-frame)[https://github.com/day8/re-frame] which keeps a strict, single source of truth:

Source: https://day8.github.io/re-frame/a-loop/#the-data-loop

This picture says it all: any change comes with consequences, state changes. This centrally.
I haven't seen any JS-based library matching with this ideology.

If you want to run an app from anywhere, desktop or mobile, display the username while the user renames it, do you really want to update it in multiple stores or in one central place?

Thanks for your thoughts and feedback 😎

[honuuk]

I think the loop in the image you shared is already basically how React works, even without any state management library.

In React, user actions update state, React notices the change, and then re-renders the relevant components to update the UI. So in a way, the data loop already exists as part of React itself.

From there, the interesting question (at least to me) is:
when we introduce a global state library, which approach fits this model better — something like Redux that enforces a single store and a strict structure, or something more flexible like Zustand?

Personally, I don’t think single source of truth has to mean a single store. Even with multiple stores, as long as each piece of data has one clear, authoritative place in the app, that still feels like a single source of truth to me.

As apps grow, state naturally splits into different domains. In Redux, putting everything into one store can sometimes make things more complex over time. With Zustand, you can split state by domain, create multiple stores, and compose them pretty easily.

That flexibility is why I tend to prefer Zustand — it keeps the “single source of truth” idea per domain, while scaling in a way that feels more natural to me.

[binarykitchen]

Thanks. Just did a npm install --save zustand ... more to come 😅

What if I maintain one Zustand domain only, for the whole app, then this time machine technique can be still applied?

[honuuk]

Yes, exactly. Zustand can still use the Redux DevTools, so the time-machine technique is still possible even with Zustand.

https://zustand.docs.pmnd.rs/middlewares/devtools

[binarykitchen]

Hmmmm, wouldn't that pose a problem?

I've studied your documentation, like advantages + disadvantages between Redux and Zustand. And the time machine technique hasn't been mentioned in these comparisons.

If you want to maintain a good reputation, I would add a note under https://github.com/pmndrs/zustand#redux-devtools mentioning that the time machine thing only works when there is one single domain.

What do you think?

[honuuk]

The time machine technique is still possible with multiple stores, but each store has its own timeline rather than a single shared one.
If you want to manage a single, global timeline, using a single store is the way to go.

As I understand zustand, it’s an unopinionated library, so the current documentation feels sufficient to me.
That said, I’m curious how the maintainers think about this.

[binarykitchen]

Exactly @honuuk I'm after a time machine and therefore searching for a state management framework which does not allow multiple stores.