State management is a huge and important part of a big application. In libraries like React, Redux has always been popular.
However, in past few d...
For further actions, you may consider blocking this person and/or reporting abuse
Hi, I'm a Redux maintainer.
I can assure you that Redux is not "deprecated", "dead", or "dying". Also, while Context is useful, it is not a replacement for Redux.
Redux will continue to be very relevant and useful for a long time. It's currently used by 50% of React apps, and lots of folks are continuing to learn it on a daily basis.
I covered this and a number of reasons to use Redux in my Reactathon 2019 talk on "The State of Redux", and my post Redux - Not Dead Yet!.
TL;DR:
Related to that, you might also want to read through these resources:
In addition, our new Redux Toolkit package is now our recommended approach for writing Redux logic. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once.
Thanks for the resources, Mark! I will surely read and search more about it
Redux just moves your state management to a separate place. In other words it applies separation of concerns (single responsibility principle). As a result, your "view" code does less stuff and state management can be separately focused on.
When should you do this? When your React code gets too complicated to handle (because of heavy state management) and you feel it would be best to separate state management and move it elsewhere. Otherwise using React context is fine.
An additional consideration is that Redux and everything it requires (thunk, Sagas / redux-observables) are fairly complicated. This should be considered when deciding whether to introduce it or not.
EDIT: It's not deprecated. You just may not needed.
Start without it, but use functions to get shared state. The functions will make transitioning to a state machine easier down the line.
Add redux/some-statemachine when/if the situation starts warranting it.
I love the reducer/redux/flux/(what do we actually call it?) pattern, but I never use it while prototyping.
Also if the implementers dont know functional patterns already, then the learning curve to efficient use is gonna be that much steeper.
Flux is amazing.
I think the structure of separating everything (actions, reducers) in different files has made Redux complex. Otherwise, it's good
I rarely put related code in different files when using redux.
That usually only happens when i hit the ~180 line limit or if i have lots of smaller definitions in it. :)
I love redux! However, I still like to follow a particular advice one of my colleagues gave me when I tried to learn it some years ago:
Looks like a good advice
I'm still convinced Redux is great if you build your application in the right way.
Just let the data flow through the state, let your components render accordingly and try not to bloat your components with code that could be placed in an action.
I've started a new project last week with Redux toolkit and I have to say it's really easy to get started and it scales out well if you define your slices properly.
I did, however, decouple the component from the slice because there's almost never a 1-to-1 relationship between a slice of the state and a component.
If your app is simple enough,
useStateanduseReducercan cover it, don't need itIf your app is quote complex ( in terms of
actionsand data model), you need to bring in quote a lot of other libs that makereduxbearable ... but it's still gonna get very verbose.It has a niche in my opinion, where your data model isn't that complex, but you have a lot of actions you can do on it.
I've used it extensively in the past in 2 very large apps, always gets annoying to maintain as you grow.
Yes!
useStatereduces a lot of pain 💓I will not use it right off the bat just because someone tells me to do so unless the scenario is telling me that hooks are making too much noise around my component, but then again instead of putting all hooks inside a component, why not just move it into a custom hook?
Beware of random tweets.
Those are opinions 🙂
My point still stands.
What we call Redux are actually two things:
I believe most engineers tend to add more application level state than they should, creating weird couplings and making things unnecessary complex. Ie, do you really need the data from those records to application level state?
More to that, action/reducer combination can get more complex than what it should. Mostly because engineers also tend to couple these as well.
Redux is a mess in a large team/app, without a properly use it can even lock the browser and you never will not know why. It's powerful, but needs to be used with careful.
Teams make the same bad state without it in my experience.
The difference being, with' a state-manager, you know' when your state is a mess. :)
We can use Service Pattern Along With RxJs (like we do it in angular) ,... It can replace redux right ?
built and app recently without redux and it sucked managing all the different states via each component
To be honest, Mobx is my choice.