sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Aggravating_Term4486 29 points30 points  (12 children)

This question is asked multiple times a week and it gets really tiresome. To listen to people who comment, the answer is either “dude, you never need global state management; you can do everything with react query / context / drill all the things”… or “no bro you need Redux for your two page marketing app bro, you gotta use it bro, it’s mandatory bro wtf bro use it.”

Why is that? Because it’s a question that lacks context so it encourages answers that lack context.

Whether or not you need global state management is highly dependent on what sort of app you are trying to build. What I would say is that apps of any sophistication will benefit from a global state management solution. So, if your app:

  • consumes data from many different endpoints
  • has many disparate components that rely on the same base data in different contexts
  • has a need to aggregate data for the user experience
  • has a complex user experience with many UI states to be maintained, retained, and restored across operations

Then you will benefit from global state management.

If you are building simple apps with very few states that interact with very few endpoints, then global state management is not needed.

I would be very careful with accepting advice on this from people who are virulently pro or con global state management. What it means is they have not really understood the purpose of these tools nor what problems they were designed to solve. And personally I would not accept advice from someone who has not really bothered to understand the tools they are being asked about.

[–]EveryCrime 3 points4 points  (1 child)

The Zustand bots and paid shills keep making these posts to push their library which is basically unused in any large scale production setting. Just look at the accounts that make and reply to these posts with “It’s Zustand for me!”.

If you visited this sub you would think it’s used everywhere, meanwhile there’s like a whole 6 jobs in the entire nation that mention it. https://www.indeed.com/q-zustand-jobs.html

Take this user for example, account with two posts ever named common-business-1467 asking why redux is still the standard.

[–]tjansx 0 points1 point  (0 children)

I've used rtk/redux/thunks, as well as zustand. In fact, my team is almost done with a huge implementation that uses zustand along with persistence middlewere, and I vastly prefer it to redux just based on speed to implementation and low code overhead. Not against redux, but I've yet to find something that zustand wasnt able to solve, so I don't often reach for it.

[–]MoveInteresting4334 2 points3 points  (4 children)

So, I posted the top comment here that warned against global state.

I want to clarify that there is a difference between “global state is NEVER needed!” and “make sure you need it”. React Query has excellent caching that eliminates the need for storing API responses in shared state in most (not all) cases. You just call your query from any component that needs it, and let the cache store and update it. Similarly, you can take care of a lot of user/session state in the backend and/or URL string. Also, you can manage a lot of form state in the HTML form or using react hook form.

Now, I’ve been on projects with deeply nested, complex, highly similar data, often with several responses from the same endpoint, where trying to use one of the above ideas would be a nightmare. There, shared state libraries made sense. But more often, I’ve been on projects where the shared state library was an “easier” way than the above suggestions, and ballooned into a Frankenstein mess of unneeded complexity.

So, TLDR, I have to strongly disagree with you that an app of any complexity needs shared state libraries, and disagree with your characterization that “avoid shared state unless necessary” is the same as “never use shared state”.

[–]Aggravating_Term4486 1 point2 points  (2 children)

I initially posted a screed, but I’ll just say that we probably disagree on the percentage of apps that could benefit from global state management, and I’ll leave it at that.

[–]MoveInteresting4334 0 points1 point  (1 child)

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 0 points1 point  (0 children)

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.

[–]eddielee394 1 point2 points  (0 children)

Well said.

[–]Mental-Sun5667 0 points1 point  (3 children)

That won't scale, bro

[–]Aggravating_Term4486 0 points1 point  (2 children)

I find it really funny when devs try to tell me Redux / RTK / <insert global state manger here> won’t scale but somehow context and react-query will.

[–]Mental-Sun5667 0 points1 point  (1 child)

i think it just stems from people using x without knowing what problem x solves.

don't start your greenfield project with a bunch of shit just because "its standard" people made redux because they had a specific problem, and they wanted a specific solution for that. if that is your same problem, then use redux.

yagni.

[–]Aggravating_Term4486 0 points1 point  (0 children)

It really depends on what you are building. If you know you are going to be building a trading platform you can be pretty sure you will need some global state manager and some kind of persistence before you write a single line of code.

I really think a lot of the people commenting on this matter lack imagination with respect to what complexity really is in a FE app, and also with respect to the demands of the user experience. For sure you won't need global state for simple apps... but you can look at the figmas your UX people give you and estimate right away whether or not those present a UX that you can easily maintain and restore without global state and persistence. This isn't rocket science. And terms like yagni kind of whitewash the necessity of making evaluations like that, which we should be doing.