There has been a lot of talk lately of why Redux is not a good option anymore for state management, and why we should use hooks & the React Con...
For further actions, you may consider blocking this person and/or reporting abuse
Hi :) Since I got quoted here, I'd like to add some additional, er, "context" to the discussion :)
The big thing here is that Context and Redux are very different tools that solve different problems, with some overlap.
Context is not a "state management" tool. Its only purpose is to make a single value accessible to a nested tree of React components. It's up to you to decide what that value is, and how it's created. Typically, that's done using data from React component state, ie, useState and useReducer. So, you're actually doing all the "state management" yourself - Context just gives you a way to pass it down the tree.
Redux is a library and a pattern for separating your state update logic from the rest of your app, and making it easy to trace when/where/why/how your state has changed. It also gives your whole app the ability to access any piece of state in any component.
So, yes, you can use both of them to pass data down, but they're not the same thing.
For more details, see my posts Redux - Not Dead Yet! and React, Redux, and Context Behavior
I'm so happy to have a Redux maintainer comment here! Thanks for the additional references!
I'm glad somebody really stands out and puts such great resources around Redux and how it should be used.
I'm aware of and agree about the Context camparison - that it's not ok. Context is just a dumb provider of storing data in a React Component that is then passing it to anywhere in a React tree. Now to be fair, Redux is also the kind of library that is letting you do most of the work, and it is just imposing some simple rules.
Probably I did not make this article a lot of justice not stating the many anti-patterns or ugly things that can be created using the Context API - as having the tens or hundreds of context providers in your app :).
Wow!!, this is a whole right perspective of why Redux is still important!
Many React devs I've met would choose Context API as the default way to manage global state. Little did they know is that without setting Context API properly, it could affect the entire application's performance.
I came across a problem where Context API would re-render every child components that it wrapped. Even memoizing the child components would still cause them to re-render. This was a big no-no for our application since it is data-heavy and will keep on growing in the future.
With Redux, it allows my team and I to debug the application easily, separate the UI layer away from the data, and be able to understand what is going with the application at all times. It is the tooling and mindset of Redux that many developers do not understand why it is such a great library. They focus too much on the boilerplate code, but in reality, it's that boilerplate code that makes maintaining the application a breeze.
Sure, not everyone needs Redux for a blog page. But when you are dealing with an application that will grow and be used by many users, you need a convention defined for you and your team to follow. When you can manage and understand the state, the actions and the UI separately in your application, only then will you appreciate Redux's beauty.
I think it comes down to size of the application I've mentioned this on another thread/post before. Your post even touches on it to some extent but if you need a highly testable code base using state/Context can make it much harder. This is because you have to essentially test the component and the state at the same time. With redux you can do these two things mostly independently (you could argue that you still need tests on how your component reacts to certain state updates and so forth).
I also feel like redux 'handles' global state in a much more maintable way for larger applications. However this is pretty much entirely a preference I don't think it's impossible to use Context API/state I think you might just have to be a bit more delligent with how you design your application.
Prior to my most recent project I was using a mix of the Context API and normal react state. However I ran into the problems of testing that I mentioned above. However that's just my two cents I'd be curious to see how others feel!
TL;DR: I feel there is a place for both it depends on the size and testing requirements of a project
Nicely said. With Redux we can have independent tests for 3 parts:
Yeah my structure is usually that of:
I haven't actually got around to trying react-saga and am just using react thunk. But I should get around to trying that out too
I did try both and as a beginner I prefer to go with Context API because it is so easy to get started with and there is no external package to install but after reading this post I understand why Redux might be the best choice for bigger project.
I'm now considering diving in Redux deeper to get more job opportunities later!
Please consider using learning materials from the official Redux website and Mark's blog.
A lot of old Redux videos and learning materials might not follow the latest best practices. Good luck!
Will do, thank you!
After 3 years redux coding, I turn to usie only useReducer + props without Context, that is the most simple solution. If I faced with complex problem, then change useReducer with useSagaReducer, without use any global state.
so i think good to know about redux, redux-saga and choose lightest state management for your app - depend complexity.
I had no idea of the
useSagaReducerhook, pretty cool!As of 2020 I keep reading everywhere that Redux should be used anymore, but I fail to find what to replace it with. The closest I found was someone who reimplemented Redux with useContext and useReducer, but to me it just feels like a doing a new worse Redux? (No proper logging, time travel, observables...)
Even Dan Abramov says he hates Redux but never suggests a proper way to replace it... Maybe it's because the global store is now considered a bad thing?
Give a try to Effector. Its framework agnostic tiny reactive library, wich come with selectors and thunks/sagas out of the box.
After a three year's of redux/mobx and some apollo, effector is just a breath of fresh air for me.๐๐
Thanks! I'll check it out when I get some time!
I think it's nice that the core React team is not suggesting something in particular. If they would have done this, it would have hurt the ecosystem for sure - as it would limit innovations and cool ideas. Redux aside, there are a ton of other very cool state management libraries like MobX, Recoil, Zustand, and many more.
GraphQL is an option. Now while GraphQL is not a replacement for Redux it does help to reduce the need for using it.
If the APIs we are using are providing GraphQL then sure! I would not require an API team to build a GraphQL API only for a frontend application. There needs to be multiple consumers or higher business value for that GraphQL API, otherwise, we cannot justify the added complexity server-side.
Great article, some fantastic points.
I've seen (in another article) coding using Redux and code using Context side by side, and I noticed how similar they actually were - the version using Context also used immutability, reducers, actions etcetera ... the amount of boilerplate saved was minor. Coupled with the fact that, as your application gets bigger, you probably want Redux anyway, I wonder why then not choose Redux right away.
On thing that make Redux complex to work with is managing and manipulating state in an immutable way, which gets complex fast. But the funny thing is that you have to do it anyway, also with Context and with useReducer. The code to manage state immutably can get hairy fast but there are tools/libraries to make this easier.
(one complexity that I feel Redux does have is in its numerous "side effect" management libraries such as Thunks and Sagas, this is adding to the learning curve)
But one thing is absolutely true, you're right that you highlighted this: don't push state into Redux which you can just as well make component-local! I think that's where the biggest pitfalls are.
The good news is that our official Redux Toolkit package eliminates all the "boilerplate" around using Redux. 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 It also sets up the thunk middleware by default, catches accidental mutations, and more.
I just published a brand-new "Redux Essentials" core docs tutorial, which beginners "how to use Redux, the right way", using our latest recommended tools and practices like RTK and the React-Redux hooks API. I'd encourage you to check it out:
redux.js.org/tutorials/essentials/...
That's brilliant, just incredible, I wasn't aware of these tools and documentation.
Right, I see that
immeris included, Redux Thunks is included by default, there are standardized ways of creating the store, actions, reducers ...This makes everything so much simpler, in large part because it's opinionated, which cuts out huge amounts of discussions, confusion, and "choice fatigue". I say it's about time ... discussion, flexibility and "choices" are nice, but productivity and speed are nicer!
Redux has really matured, so I know what I'll choose for my next project.
Yep, that's exactly why we created Redux Toolkit :)
That's a nice move!
I can imagine the difficulty and frustration of understanding redux for beginners, especially if they don't have CS background to back up with many concepts (software architecture, best practice, data flow...). However you're very right on saying that people should consider it, as there is 50% chance that they will meet this at the job. Many apps aren't built today and they have grown big, and it costs the company a lot of money to rewrite or convert it to newer version, not to mention, from a business perspective there is no incentive to do so if the purpose is just to make it easier to developers!
This is the same as Svelte vs. React, no matter how amazing I personally think Svelte is, the job perspective is much lower than React at the moment. So I would learn React first, try to get a job, and have fun with Svelte in my spare time. Until I become a senior who gets to decide what to use, I guess have NO SAY on what to use at all. I just have to follow whatever they prefer, right? :)
Hi Annie, as a Svelte enthusiast I know what you say. I wonder if there are big apps out there build with Svelte. There is also this issue here: github.com/sveltejs/svelte/issues/... .
Yeah within the community we're discussing about showcases. It seems there are some relatively big apps, but they're not widely known. The thing is, only more people are using this, there can be more contribution for bug fix or extra libraries. I see in the report the interest to learn Svelte is quite high, so it's a good sign. :)
Haing some showcases would surely bump those numbers even more over the years, as technical decision makers look for technologies that are proven in the industry most of the time :)
Context API shouldn't be considered as a replacement for Redux. It's an alternative for classic callbacks to parent at most. It's not a state manager. If some dude says that Context will replace Redux, he's living in a fantasy. I can bearly see how to compare those two
Maybe it's dying specifically in React applications
Context (or some small library based on it like Constate), Zustand, or other solutions (or combinations thereof), and now definitely keeping an eye on Recoil.
It's also worth noting that RXDB (albeit with a lot of dependency bloat), can handle not only persistence and sync, but all of your app's state management (even if its creator said it's not a replacement for Redux in an issue comment a long time ago), if you're smart about your use of storage and in-memory together. There same is true of Firebase, AppSync, Apollo, etc.
While I've avoided Redux in my own projects for over a year now, and would personally reach for easy-peasy if I did feel like I needed Redux (I never want to look at Redux boilerplate PLUS Saga boilerplate again, just to do async at that), it's still important to know if you're looking for work (there's a good chance it'll be your employer's state management of choice).
And despite my gripes about it, Redux still does it's job and does it well (except async, that's ridiculous) in an incredibly small amount of code - it may seem like bloat compared to just context or smaller libraries mostly based on it, but it's really very small for what it does and the extensibility it offers (the boilerplate, on the other hand, definitely adds up).
As I just linked above, check out our official Redux Toolkit package if you haven't yet seen it.
Redux Toolkit is good. I should have mentioned that along with easy-peasy.
Redux toolkit is a game-changer. If you want a clear separation of global state and presentation then it can be easily and cleanly achieved with the Redux toolkit.
Hey, Alexandru-Dan-Pop, I had an interview last week in which the interviewer asked about redux 3 principles. Can you please tell me those three principles?. As I used redux in only one project but don't know the principles of redux.
Single source of truth, state is read-only, changes made with pure functions.
redux.js.org/introduction/three-pr...
Thank you so much. Now, I got it.๐๐ This link helped me a lot.
Amen.
I recently was building a React app in TypeScript and I felt some friction while I was quickly trying to set up a state management flow. Might not be a problem for everyone, but I was trying to quickly prototype something.
Naturally, I started with Redux, but went on to implement state management in Context. I believe the boilerplate set up for both the approaches is very similar, just the very big plus for me while using Context is that I get to see what exactly is happening, i.e. there is no behind the scenes.
Setting up a useReducer at the root of my app and then providing it with Context is a very simple way to get state management running. Down the tree, you use useContext to pull dispatch and the state. Once this initial setup is done, you can use it normally as Redux.
Context API. I see the trend going towards Context lately so i'm putting more effort in going that way than staying with Redux which may dissappear in a year.
"may disappear in a year"
That's not happening
Definitely not happening any time soon :)
Maybe not but context api might do the same thing to redux that react did to jquery.
It will not, as mentioned in the top comment, context API has not the same purpose as Redux.
If you doesn't use middleware, you surely don't really need to use Redux.
Context API + useReducer hooks would be good enough for many situations:
Thanks Alexandru-Dan for this article. I am not well versed in React (for now) but having created many applications in Angular I can tell you the Redux fatigue is here. Luckily we have good toolkits and best practices but we often end up with a different implementation by developer by team.
The most common question is: Should everything be in Redux? Should every action performed in the application be handled by Redux? Common sense tells me that Redux should only manage (persistent) state, but then come a problem because we end up with a very hybrid solution with some actions (search, filters, authentication) in Redux and some others not (CRUD like actions on an entity).
I still like Redux but it adds a lot of boilerplate and complexities and it is sometimes very hard to teach it in teams of junior or mid-level developers. This is sometimes a point that is overlooked by documentations in the sense that when we manage multiple teams and multiple developers the best solution is often the most universal, opinionated and strict as to avoid too many different implementations that increase technical debt and decrease readability and maintainability.
And it's becoming even more difficult because of SSR and Pre-Rendered Sites as state is not (easily) shared between server and client.
So it's nice to read different opinions on the question of Redux.
Good points!
I think Redux is getting more mature with solutions like Redux Toolkit & RTK Query (that is still alpha but sounds promising).
Angular also has the NGRX store that is a Redux-like implementation for the Angular ecosystem - I think this proves the Redux popularity.
React Query is another popular solution to avoid boilerplate - but this one has a learning curve as well for advanced usage. But it's nice because it will invalidate and re-fetch the cached data.
SSR & pre-rendered sites - haven't used Redux in those scenarios - so I honestly can't make a statement for it. I only used Redux for fully CSR apps.
As a small conclusion, if you spend too much time researching what advantages Redux brings or what cons it has, you might not need it. You will know when you need it in those cases:
I appreciate the article, but we really need to be cautious about writing "depends on the size of the project or situation" type articles related to Javascript development choices.
In particular, with React, Redux has been a major source of project delays and near failures in my 4 years of React dev experience. Also, arguing over "redux vs mobix vs context" has created thrashing on projects, division in the community and another wave of "javascript fatigue".
Use Redux for legacy applications only! Use Context going forward. ...And spend time focusing on your product, not hemming and hawing over esoteric concerns.
Thanks for this Alexandru! I love redux but whenever I post anything about, I get a lot of criticism which I really don't care about. :)
Glad you liked it!
I guess people got scared or sick of Redux for wrong reasons. Maybe they have seen really bad React / Redux apps that made them think it's because of Redux. It's not, if used correctly it's a very good state manager & makes code easier to test and more maintainable.
Yep,
useReducercan also be used for complex local state. When that state needs to be shared it can be lifted in a Context or in Redux.Redux is not going away anytime soon many companies still expect React developers to at least know a state library like Redux.
Redux packages gives us a certain recipe that we can follow and build rather than messing around with different react hook based stuff.
Look at meiosis pattern on Dev to
Regards
the poll said redux will die in 3years from 2020 so why the need to learn it when you can spend time learning Context API
I'd love it if you wanted to dissect my Redux one line replacement hook... useSync
dev.to/chadsteele/redux-one-liner-...
Software for making that gif ?
Thanks for this wonderful article !