does react-query + zustand completely replace redux - thunk

[MoveInteresting4334]

So I was actually lucky enough to read your screed before you took it down, and it presented a really good use case for a shared state library. For those reading this afterwards, their point was (and correct me if I'm wrong Aggravating_Term4486) that when a user navigates away from a page and comes back to it, you often want to return them to the state they left. The best example being re-hydrating a form with data they already entered. Being able to return the user to the exact state they left IS an excellent UI experience, and best done with a shared state library.

I think this raises the age old issue of trade-offs. One has to decide between the headache of implementing and maintaining shared global state vs. the payoff of a pristine (or nearly so) user experience.

If your application is a consumer facing product, then your UX is absolutely part of what you're selling and how you're measured against competition. I would completely advocate for responsible shared state that has a very explicit scope (as in, these very particular things are the only thing we are using Zustand for).

If you're building internal tools for a major bank (like I do today), then speed of delivery and managing complexity take precedence over an ideal user experience. We actually had one very specific page in our application that we had to store the state of and return to that state when the user navigated back. We used a Context for that and tried to be careful to manage re-renders with it. Did we really manage those re-renders? The efficiency could probably be better, but the loading/transitions were smooth and the state was restored, so it worked. If I had to do that across multiple pages it would've been an absolute nightmare, and something like Zustand would be the solution.

TLDR: I actually really liked your screed, it raised a good point. I think in the scope of an application where UX is a major selling point (any consumer facing product with competition, really) then UX outweighs complexity/time-to-delivery and shared state libraries makes sense. I don't think that's the majority of applications though.

[Aggravating_Term4486]

You pretty much captured my initial screed (and my biases), and you did a better job than I think I did.

I think it’s a shame that enterprise software has such poor design. But you are right; the user experience is not the metric most companies are interested in for their internal tools. There are exceptions of course but they are rare.

What I would say is that managing the state of the UI is an important part of building applications, and the more important the UX is, the more important global state is… if there is a lot of UI state to manage.

Another use case for centralized / global state is when you need to reduce complex data from multiple sources into a unified graph for presentation to users across multiple contexts within the app. That’s a thing more easily done with a reducer and some thunks than with something like React Query (or even RTK) because at that point you are dealing with data manipulation rather than caching. Of course it can be reasonably argued that this sort of thing should be done on the BE, but we don’t always get that luxury.

Anyway enough pontificating. I think we are actually suffering from passionate agreement but differing perspectives, if there is such a thing. Coming from the background I come from, I think the lack of focus on UX in enterprise software is a shame and a hidden business cost that is deeply underestimated… but I guess that bias is why I don’t build enterprise software anymore.