DEV Community

Discussion on: Why I Stopped Using Redux

Collapse
 
chamsddine profile image
Bouzaine Chamsddine

React-Query and context api can never replace redux (they are not the same thing ).and he is not overkill , the one time i think redux is overkill is if you are working on small projects , you can argue that we can use other state management solutions like xstate maybe but to build a scalable and maintainable application we need a centralized state .

Collapse
 
stephyswe profile image
Stephanie • Edited

On one router page we make 15 action based api calls . How you handle that w/o redux ?

You also have persist state in redux.

Collapse
 
g_abud profile image
Gabriel Abud

At a certain complexity it may make sense to start using Redux. I am not against Redux as a tool (I say that in the first paragraph) and I think its design is excellent, I'm more against what it encourages us to do.

Having said that you can easily do that many calls with React Query and SWR and have them be cached so they are not refetched every time. You simply use a hook in the components that are needed and don't have to worry about managing your own global store.

Thread Thread
 
mattpocockuk profile image
Matt Pocock

I'd argue that at a low level of complexity, use useReducer, useState and useContext. At a high level of complexity, use XState/useContext. XState handles complexity much better than Redux.

Thread Thread
 
theodesp profile image
Theofanis Despoudis

That implies that you know how to create correct state machines...

Collapse
 
serhiiohorodnyk profile image
Serhii Ohorodnyk

That is very true - they are not the same things. But that is exactly the point of this article: redux is a global state management library, while react-query (or SWR) are cache management libraries. And the reality today is that most web applications (I would dare to say more than 95%) do not need global state management at scale, they need sophisticated caching library, because "single point of truth" is not in redux state - it's in the DB, coming from your api.

And I would argue about following "to build a scalable and maintainable application we need a centralized state" - I've refactored so many relatively complex react applications away from redux and they all became a lot more predictable and thus more scaleable and easier to maintain (not to mention that number of lines became 5-10 times less).

So if you have a source code example of an app that needs redux to be maintainable - I'd be happy to check it out!

Collapse
 
jochri3 profile image
Christian Lisangola

I totally Agree with you.I've used redux for many year, and also redux-toolkit that has become the set of tools that is built by the redux team and is now the official library that the teams recommends. I agree that it has solved many redux problems in terme of boilerplate, complexe logic, etc..And it's more beginner friendly that redux.But, since last year, i've started using react-query.

When people say that redux and react-query don't try to solve the same problem, i don't really at 100%.Today redux is mainly used for trying to manager the server state if even it can be used for something else(for which the context API would be sufficient).What i really love is the way it's implements the concept of "single source of truth", cuz in the redux word, the "single source of truth" is just an plain JS object sitting in the client application, so to try make your redux store in sync with the API, they are many other solutions to plug on or reimplement some logic manually to make your redux logic more complex and less understandable.That's where react-query come in action, and i really believe that it will "kill" for "new projets" in some years, because of the concept of how it implements the "single source of truth" with your collection bound and in sync with the updated server state and for any other mechanism , no need to write complex code because everything you need you get if with just some few configurations.

My English is actually very bad, please understand that i'm French🤗!

Collapse
 
brianl profile image
Brian Lim

Redux being "overkill" doesn't have much to do with "scale" (that's a misconception) but the requirements

medium.com/@dan_abramov/you-might-...

The man himself

If you don't need any of those requirements listed, using redux could be an exercise in technical supremacy and machoism. Or perhaps premature optimization.

There's also many other non-technical requirements for using redux that I won't speak to. For example, it makes interviewing or filtering easier. Yes redux, especially a lot of redux? You probably have enough frontend. No redux? You probably don't. If you work somewhere where everyone has a Ph.D. and skill is not an issue because everyone learned Redux in four hours then maybe everyone is excited and will use "centralized state". But if you don't, if you work somewhere with enterprise software where everyone wants to get home on time not work overtime and most important not spend hours and hours writing boilerplate (or engineering solutions to avoid boilerplate, a fraught business itself), then redux could be a curse.

Redux is intended to solve a problem if you don't have that problem you don't need it.

Collapse
 
captaincodeman profile image
Simon Green • Edited

I honestly think that blog post is a bit of a cop-out. The reality is that what Redux does is great, but it does it all in such a complicated way that it makes things difficult, so difficult that it may not be worth it unless you're doing a significant problem.

But you can do all that Redux does in a much simpler way so you don't have to write as much code and do it all with significantly fewer bytes (more the ecosystem of extras that you end up including than the core lib itself)

More in-depth thoughts (ranting) about Redux an an alternative I came up with:
captaincodeman.com/2020/05/31/intr...

Collapse
 
kravemir profile image
Miroslav Kravec • Edited

one time i think redux is overkill is if you are working on small projects ... to build a scalable and maintainable application we need a centralized state

Redux is a very wrong tool for any front-end (dumb client/interface) of information systems, where the back-end is the single source of truth - the centralized state.

Even user's settings are stored in BE, and therefore should be treated as network resource. I couldn't imagine working with information system, which wouldn't remember my settings across different sessions / browsers / computers. Rather, not have any user settings at all, then.

However, redux might be a good choice for rich applications, where the front-end is practically a full-featured desktop application, and the back-end serves as mere storage for BLOBs (with metadata).

My opinion is based on experience with a large / enterprise application using Apollo GraphQL. And, that I've just migrated my pet project from custom-crafted very-sub-optimal redux caching solution to react-query.

Collapse
 
louiszen profile image
Louiszen

Once you use MobX, you will understand Redux is actually a garbage.