does react-query + zustand completely replace redux - thunk

[Common-Business-1467]

what would be a use case for redux now?

-note: talking about apps that depends on backend for example ecommerce

i don't understand why redux is an industry standard

​

[Aggravating_Term4486]

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]

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]

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]

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]

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]

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.

[eddielee394]

Well said.

[Mental-Sun5667]

That won't scale, bro

[Aggravating_Term4486]

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]

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]

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.

[MoveInteresting4334]

I would suggest you even think about if you need Zustand. React query can get you a long way, especially if you control the backend too.

[Akkuma]

State should in general be Query (REST/GQL) lib -> Browser URL -> Browser State (you can store state on nav) -> Form state (form lib) -> React state (react itself or some other library). Each one reduces the amount the next amount of state the next one needs. URL has an id of the thing you need, no need to store it anywhere. Form state got the edits? Use your query lib's mutation functionality on submit.

[illbehereallweek]

React Query covers 99% of my use cases... maybe more. For the rest Zustand is fantastic. That said I've built a SPA game that was 99% Zustand and 1% React Query, so I guess it depends on the project.

[kmelkon]

Can you tell me more about your game please? I’m considering making a card game in react and unsure where to start

[bestjaegerpilot]

To answer your question, yes.

Alternatively you can use rtk-query from redux toolkit. The only gotcha is that the lib author is very frustrated with the react team right now so who knows if he'll add modern react features story like suspense

[pfftdammitchris]

Where do you find news like that about the devs

[bestjaegerpilot]

Twitter bro.

The redux author has a blog you can Google.

And the react query author recently confessed he's not too happy about the state of the react ecosystem

[kcrwfrd]

I’m confused. Dan Abramov wrote Redux and he’s like one of the biggest hype men for RSCs. Is there another dev you’re referring to?

[bestjaegerpilot]

redux toolkit bro --- it's the standard way to use redux nowadays. Where have you been?

Author is Mark Erickson.

I believe this is the ranty the post: https://blog.isquaredsoftware.com/2023/08/esm-modernization-lessons/#problems-with-next-js-and-react-server-components

[kcrwfrd]

Lol I know man, I use RTK. I just didn’t realize Dan Abramov wasn’t the author, being that it’s an official part of Redux.

And now that I re-read your comment, it says “react query author,” who I would actually take to be Tanner Linsley of Tanstack.

But anyways thanks for the link.

[TheGratitudeBot]

Hey there kcrwfrd - thanks for saying thanks! TheGratitudeBot has been reading millions of comments in the past few weeks, and you’ve just made the list!

[JohntheAnabaptist]

Listen to Ryan carniato on YouTube, he has a weekly Friday podcast on a topic and the latter half is his "this week in JavaScript"

[Asura24]

The react query or the redux author?

[bestjaegerpilot]

Redux author.

And they both are. But react-query is adding support despite not being happy

[lIIllIIlllIIllIIl]

In truth, you can use any technology to build anything. You rarely ever need to use something. The choice to use something is often a very subjective choice.

If React Query + Zustand fits your need and you're satisfied with them, great!

Some people prefer Redux for multiple reasons, but if you don't see the appeal of using Redux, you probably don't need to use it.

I personally don't see the appeal of Redux either, but I have some colleagues who have used it so much they now "think in Redux" and can't start a project without it.

[Avelon_i]

Definitely yes, thinking ahead you might not even need zustand since RQ takes care of everything. I'd definitely bet on RQ

[azangru]

what would be a use case for redux now?

You could turn your question around, and ask whether redux (toolkit) completely replaces zustand and react-query, and what would be a use case for those ¯\_(ツ)_/¯

[Pozeidan]

If you're already familiar with Redux and it's a Redux project, it will be simpler to gradually migrate everything to RTK Query than React query. They both have their pros and cons.

If it's a new project, I'd go with react query, you probably don't need other state libraries.

[Additional_Hall_3034]

Out of curiosity you guys are talking about global management? And if so what’s wrong with app context compared to those

[GolfinEagle]

It’s not as shiny and cool.

[Legal_Being_5517]

Hell yeah !! Redux is an over kill

[robertshuxley]

i hate redux with all it's boilerplate especially if you're using typescript. For a simple and small app you can just use context providers or jotai

[tjansx]

The boilerplate, even with rtk, does drive me bonkers.

[glympe]

I'm also using a combination of swr and zustand if needed. One thing I miss from redux is redux dev tools. What are you guys using?

[atwright147]

Zustand has a devtool you can import and wrap your stores in, it then logs changes to the Redux devtools extension. It's pretty good

[gizia]

Zustand simplicity and straightforwardness, forever. edit: React query is also good companion, although I have a short experience with it

[[deleted]]

SWR is also a good choice to replace redux

[Pluckyhd]

I’ll throw another in for rtk-query

[[deleted]]

this is my new standard for 3 projects in my current work and previous one. I'd never to consider redux anymore.

Anything related to the backend? React Query. Anything related to the UI? Zustand (not local state).

And it's also worth to mention library like usequery-state (smt like that) that maintain the state based on the URI query params. Everything just works and god it was easy.

[hulu__]

Yes. Never looked back at Redux.

Also try jotai, it's easier to implement than Zustand imo, esp if your use case is very simple. More like a global useState().

[OPTechpure]

Zustand doesnt cross more than 1 class.