Redux – Not Dead Yet
Blogged Answers: Redux - Not Dead Yet!

	
  
    
    
	
        
	    
    	This is a post in the Blogged Answers series.
        
	 
  
  
     Some clarification on what's going on with Redux 

I'm a Redux maintainer.  There's been a lot of confusion, claims, and misinformation about Redux going around lately, and I want to help clear things up.


Note: Updated 2020-12 with additional info and links


TL;DR 🔗︎ 

Is Redux dead, dying, deprecated, or about to be replaced? 🔗︎ 

No.

Are there situations where you don't need Redux? 🔗︎ 

Sure, but that's always been true.

A Longer Explanation 🔗︎ 

There's been a whole slew of comments and articles lately that boil down to people asking "Is Redux dead?", or asserting that "Tool X replaces Redux".  I'll recap several sources of confusion, and explain what's actually going on.

"Redux is Overused" 🔗︎ 

Where's this coming from? 🔗︎ 

Redux has been around since 2015.  In "JS library years", that's like... forever :)  It got very popular very quickly, and as a result, a lot of people were told they had to use Redux, without actually understanding the tradeoffs involved and when it actually makes sense to use Redux.  So, there's been some inevitable backlash, and people have looked for alternatives, including adopting other state management libraries or creating their own.

As part of that, there are recurring waves of Twitter comments that seem to pop up every few months, with various comments to the effect that that "Redux is dead", "HAHA LOOK PEOPLE ARE STILL USING REDUX!", and so on.  These tweets and various others get heavily retweeted, and the ensuing discussion ricochets around Twitter for a while.

Clearing the Confusion 🔗︎ 

The Redux maintainers (first Dan Abramov and Andrew Clark, now Tim Dorr and myself) have always said that you might not need Redux.  There are excellent reasons to use Redux, but it may not be the best fit for your situation.  Like any tool, it's important to understand the tradeoffs and benefits before deciding to use something.

I've seen plenty of comments amongst the Twitterati that people have opted to move away from Redux to something else.  But, at the same time, my own estimates are that somewhere between 50-60% of all React apps use Redux, plus all of its usage with other JS frameworks like Angular, Ember, and Vue, and that is a userbase that isn't just going to disappear overnight.  (There's also a big gap between what gets chatted about at lightning speed on social media, and what people are actually doing in "the real world".)

It's also worth noting that Redux is not owned by Facebook - it's a separate open-source project.  Both of its creators (Dan Abramov and Andrew Clark) now work at Facebook, but Tim Dorr and I have no affiliation with Facebook at all.  We talk with the React team to help coordinate future plans, but Redux doesn't belong to them.

"The new Context API can replace Redux" 🔗︎ 

Where's this coming from? 🔗︎ 

React 16.3 is introducing a new stable version of the context API, which is intended to replace the old unstable API.  Context is specifically intended for the use case of passing data to deeply nested React components.  That's one of the reasons why some people have chosen to use Redux, and so there's been claims that the new context API will replace Redux.

Clearing the Confusion 🔗︎ 

Yes, the new context API is going to be great for passing down data to deeply nested components - that's exactly what it was designed for.  If you're only using Redux to avoid passing down props, context could replace Redux - but then you probably didn't need Redux in the first place.  Context also doesn't give you anything like the Redux DevTools, the ability to trace your state updates, middleware to add centralized application logic, and other powerful capabilities that Redux enables.

It's also worth noting that context is just a mechanism for making a value available to a nested subtree of components, and it's not a state management approach in and of itself.  In fact, you have to write whatever state handling logic you need on top of that, in order to define the value that gets passed into a context provider.  Typically that's just done through React component state, but the point is that context itself doesn't manage state for you in any way.

I've also seen a lot of people say that "React-Redux uses context internally!".  This is technically true, but when phrased that way, it's very misleading.  React-Redux does use context, but only to pass down the store instance, not the current state value.  For more details on how context and React-Redux behave differently, see my post React, Redux, and Context Behavior, as well as my extensive description of React-Redux's internals in The History and Implementation of React-Redux and A Deep Dive into React-Redux.

"GraphQL can replace Redux" 🔗︎ 

Where's this coming from? 🔗︎ 

Somewhat similarly, there's been a lot of noise around GraphQL and the Apollo Client.  There have been articles specifically claiming that "GraphQL will let you replace Redux".  Also, Apollo has a new apollo-link-state addon that can handle client-side state, and there's been discussion that that can also help replace Redux.

Clearing the Confusion 🔗︎ 

I'd agree that data fetching via GraphQL, and especially with Apollo, will likely reduce or eliminate your data-fetching related Redux code.  And again, if that's all you were using Redux for, you probably wouldn't need Redux after moving all the data-fetching handling into Apollo.  Apollo's client state implementation looks like it at least works to some extent, and I think Apollo ships with a DevTools setup of its own.  The Apollo team has been doing some pretty neat work, and while I don't like seeing people switch away from Redux, ultimately we all want to build great apps that help our users.  But, as with context, I'd say there's definitely use cases where Redux is going to work better than GraphQL + Apollo, and possibly without requiring as much buy-in throughout your architecture.  This is especially true if you need to do more than just fetch data or update a couple local state values, like persisting user data through page reloads or implementing complex workflow logic.  (Also, while I'm biased, the snippets I've seen of handling client state through Apollo feel very awkward to me, and not really an improvement syntactically.)

"Redux is being replaced by something from React" 🔗︎ 

Where's this coming from? 🔗︎ 

Dan Abramov gave a great talk at JS Conf Iceland where he demoed two upcoming aspects of React's "async rendering": time-slicing will allow React to split up update calculations for smoother updates, and "React Suspense" will allow deeply nested components to delay their rendering until fetched data is available.  Unfortunately, shortly after the talk, a site known for writing misleading and poorly-written articles about React put up a post claiming that "Dan Abramov announced a new 'future-fetcher' library that replaces Redux", and linked a tweet by Kent C Dodds with that statement as evidence.

Clearing the Confusion 🔗︎ 

One of the problems with social media is that it's easy for misinformation to spread quickly.  And especially in this case, because that widely-spread article about Dan announcing a "future-fetcher" library was completely and utterly wrong!  Dan's announcement was purely about async React capabilities, and had nothing to do with Redux.  In addition, Kent's tweet about Redux being replaced was literally a joke tweet in a joke Twitter "live-commentary" thread about the talk.  The article was either a complete misunderstanding of the React ecosystem, or a deliberate attempt to spread confusion and FUD.

"Redux will be replaced by React's new Hooks API" 🔗︎ 

Where's this coming from? 🔗︎ 

At ReactConf 2018, the React team announced a new API, called "Hooks".  Hooks give function components the same capabilities as class components, including the ability to have state and execute side effects after an update.

One of the new hooks is useReducer().  Some folks have suggested that useReducer(), especially in combination with the updated Context API and the useContext() hook, would eliminate the need for Redux.

Clearing the Confusion 🔗︎ 

It's certainly true that useReducer() lets you handle state updates using reducers without needing a Redux store, and useContext() lets you pass values through the React tree without needing to pass them down through every component level as props.  As already mentioned, if avoiding prop-drilling was the only reason you were using Redux (and React-Redux), then sure, Redux isn't necessary in this case.

However, as with the Context API itself, the useReducer() hook doesn't have the additional capabilities that Redux allows.  There's no time-travel debugging, no middleware, and no DevTools Extension to see how the state has changed over time.

In addition, it's totally fine to use hooks and Redux together.  In the same way that you can have class components with state connected to Redux, you can have function components with useState() or useReducer() connected to Redux too.

As a specific example, this Reddit comment discusses how Redux helped simplify their app, benefits of using Redux, and why hooks weren't a replacement for Redux.  For a contrasting view, the post From Redux to Hooks: A Case Study is a good look at situations and cases where just hooks may be sufficient.  (See the additional links on this topic at the end of this post for more comparisons.)

The Future of Redux 🔗︎ 

As a Redux maintainer, I can assure you that Redux isn't going anywhere.  The Redux core library is stable, and as I talked about in my Reactathon 2019 talk on "The State of Redux", Redux will continue to be very relevant and useful for a long time.  We're still maintaining and improving the Redux family of libraries, it's still widely used (and usage stats are continuing to grow!), and lots of folks are continuing to learn it on a daily basis.

As I've said already, there are many other great options for state-related approaches in the React ecosystem.  At the same time, there's still many excellent reasons to choose Redux:


Consistent architectural patterns
Debugging capabilities
Middleware
Addons and extensibility
Cross-platform and cross-framework usage
Depending on your app's setup, much better performance than working with just Context


It's now easier than ever to use Redux.  Our official Redux Toolkit package wraps the Redux core, and provides  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's now our recommended approach for writing Redux logic.  We've gotten amazingly positive feedback how much people enjoy using Redux Toolkit to write Redux apps, and it's being adopted rapidly.

Meanwhile, React-Redux now has a hooks API.  While connect still works fine, the hooks API is simpler and easier to use in many cases, and we're going to teach that as the default approach going forward.

As of December 2020, we've just published the first alpha version of RTK Query, an experimental data fetching and caching library built for Redux Toolkit.  Once the API is ready, we plan to

Further Resources 🔗︎ 

So with all that in mind, it's a great time to learn how to use Redux. As always, I'll close with some links to further resources:


Learning Redux:


The official Redux docs. I've completely rewritten the tutorials for 2020:


"Redux Essentials" tutorial: teaches Redux "top-down", by building a real-world app using Redux Toolkit as the default approach
"Redux Fundamentals" tutorial: teaches Redux "bottom-up", and teaches how to write Redux code by hand before showing how Redux Toolkit simplifies that Redux logic

I've got a blog post with my suggested list of resources for learning Redux
My "Practical Redux" blog tutorial series demonstrates a variety of real-world Redux and React techniques through building a sample application, and I've also created an interactive "Practical Redux" course on Educative.io.

Understanding when and why to use Redux:


The Redux FAQ entry on "When should I use Redux?"
Dan Abramov's post You Might Not Need Redux, which discusses the tradeoffs Redux asks you to make and some of the benefits you get in return
My two part post The Tao of Redux, Part 1 - Implementation and Intent and The Tao of Redux, Part 2 - Practice and Philosophy, which looks into the history and intent behind how Redux was designed, how it's meant to be used, and why common usage patterns exist.
I addressed the question of "when should I use Redux?" several different podcast appearances in 2020
In addition, the JS Party folks republished an excerpt from the podcast transcript as a post called When (and when not) to reach for Redux

Comparing Redux, Hooks, and Context


Mark Erikson - Reactathon 2019: The State of Redux
Mark Erikson: React, Redux, and Context Behavior
Dave Ceddia: React Context API vs Redux
Mike Green: You Might Not Need Redux (But You Can’t Replace It With Hooks)
Sergey Ryzhov: From Redux to Hooks: A Case Study
Eric Elliott: Do React Hooks Replace Redux?
Chris Achard: Can You Replace Redux with React Hooks?

Redux APIs


Redux Toolkit
React-Redux hooks API



	
	
	
	
	This is a post in the Blogged Answers series.
	Other posts in this series:
	
	
	
	
		Aug 08, 2023 - 
		
			Blogged Answers: My Experience Modernizing Packages to ESM 
		
		
	
		Jul 06, 2022 - 
		
			Blogged Answers: How I Estimate NPM Package Market Share (and how Redux usage compares to other libraries) 
		
		
	
		Jun 22, 2021 - 
		
			Blogged Answers: The Evolution of Redux Testing Approaches 
		
		
	
		Jan 18, 2021 - 
		
			Blogged Answers: Why React Context is Not a "State Management" Tool (and Why It Doesn't Replace Redux) 
		
		
	
		Jun 21, 2020 - 
		
			Blogged Answers: React Components, Reusability, and Abstraction 
		
		
	
		May 17, 2020 - 
		
			Blogged Answers: A (Mostly) Complete Guide to React Rendering Behavior 
		
		
	
		May 12, 2020 - 
		
			Blogged Answers: Why I Write 
		
		
	
		Feb 22, 2020 - 
		
			Blogged Answers: Why Redux Toolkit Uses Thunks for Async Logic 
		
		
	
		Feb 22, 2020 - 
		
			Blogged Answers: Coder vs Tech Lead - Balancing Roles 
		
		
	
		Jan 19, 2020 - 
		
			Blogged Answers: React, Redux, and Context Behavior 
		
		
	
		Jan 01, 2020 - 
		
			Blogged Answers: Years in Review, 2018-2019 
		
		
	
		Jan 01, 2020 - 
		
			Blogged Answers: Reasons to Use Thunks 
		
		
	
		Jan 01, 2020 - 
		
			Blogged Answers: A Comparison of Redux Batching Techniques 
		
		
	
		Nov 26, 2019 - 
		
			Blogged Answers: Learning and Using TypeScript as an App Dev and a Library Maintainer 
		
		
	
		Jul 10, 2019 - 
		
			Blogged Answers: Thoughts on React Hooks, Redux, and Separation of Concerns 
		
		
	
		Jan 19, 2019 - 
		
			Blogged Answers: Debugging Tips 
		
		
	
		Mar 29, 2018 - 
		
			Blogged Answers: Redux - Not Dead Yet!
		
		
	
		Dec 18, 2017 - 
		
			Blogged Answers: Resources for Learning Redux 
		
		
	
		Dec 18, 2017 - 
		
			Blogged Answers: Resources for Learning React 
		
		
	
		Aug 02, 2017 - 
		
			Blogged Answers: Webpack HMR vs React-Hot-Loader 
		
		
	
		Sep 14, 2016 - 
		
			How I Got Here: My Journey Into the World of Redux and Open Source 
		
		
	
	
	
 

  
