Accepted answer

As Context is no longer an experimental feature and you can use Context in your application directly and it is going to be great for passing down data to deeply nested components which what it was designed for.

As Mark Erikson has written in his blog:

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.

Redux is much more powerful and provides a large number of features that the Context API doesn't provide, also as @danAbramov mentioned

React Redux uses context internally but it doesn’t expose this fact in the public API. So you should feel much safer using context via React Redux than directly because if it changes, the burden of updating the code will be on React Redux and not you.

Its up to Redux to actually update its implementation to adhere with the latest Context API.

The latest Context API can be used for Applications where you would simply be using Redux to pass data between components, however applications which use centralised data and handle API request in Action creators using redux-thunk or redux-saga still would need Redux. Apart from this Redux has other libraries associated with it like redux-persist which allows you to save/store data in localStorage and rehydrate on refresh which is what the Context API still doesn't support.

As @dan_abramov mentioned in his blog You might not need Redux, Redux has useful applications like

  • Persist state to a local storage and then boot up from it, out of the box.
  • Pre-fill state on the server, send it to the client in HTML, and boot up from it, out of the box.
  • Serialize user actions and attach them, together with a state snapshot, to automated bug reports, so that the product developers
    can replay them to reproduce the errors.
  • Pass action objects over the network to implement collaborative environments without dramatic changes to how the code is written.
  • Maintain an undo history or implement optimistic mutations without dramatic changes to how the code is written.
  • Travel between the state history in development, and re-evaluate > the current state from the action history when the code changes, ala TDD.
  • Provide full inspection and control capabilities to the development tooling so that product developers can build custom tools for their apps.
  • Provide alternative UIs while reusing most of the business logic.

With these many applications its far too soon to say that Redux will be replaced by the new Context API.


  • If you need to use middleware for various purposes. For example logging actions, error reporting, dispatching other requests depending on the server’s response, etc.
  • When data coming from multiple endpoints influence single component/view.
  • When you want to have greater control over actions in your applications. Redux enables tracking actions and data change, it greatly simplifies debugging.
  • If you don’t want server response to directly change the state of your application. Redux adds a layer, where you can decide how, when and if this data should be applied. The observer pattern. Instead of creating multiple publishers and subscribers across the whole app, you just connect components to Redux store.

From: When to use Redux?


The only reasons to use Redux for me are:

  • You want a global state object (for various reasons, like debuggability, persistence...)
  • Your app is or will be big, and should scale to many developers: in such case you probably need a level of indirection (ie an event system): you fire events (in the past) and then people you don't know in your organisation can actually listen to them

You probably don't need the level of indirection for your whole app, so it's fine to mix styles and use local state/context and Redux both at the same time.


I prefer using redux with redux-thunk for making API calls (also using Axios) and dispatching the response to reducers. It is clean and easy to understand.

Context API is very specific to the react-redux part on how React components are connected to the store. For this, react-redux is good. But if you want to, since Context is officially supported, you could use the Context API instead of react-redux.

So, the question should be Context API vs react-redux, and not Context API vs redux. Also, the question is slightly opinionated. Since, I am familiar with react-redux and use it in all projects, I will continue to use it. (There is no incentive for me to change).

But if you are learning redux just today, and you have not used it anywhere, it is worth giving Context API a shot and replace react-redux with your custom Context API code. Maybe, it is much cleaner that way.

Personally, it is a question of familiarity. There is no clear reason to choose one over the other because they are equivalent. And internally, react-redux uses Context anyways.


If you are using Redux only to avoid passing props down to deeply nested components, then you could replace Redux with the Context API. It is exactly intended for this use case.

On the other hand, if you are using Redux for everything else (having a predictable state container, handling your application's logic outside of your components, centralizing your application's state, using Redux DevTools to track when, where, why, and how your application's state changed, or using plugins such as Redux Form, Redux Saga, Redux Undo, Redux Persist, Redux Logger, etc…), then there is absolutely no reason for you to abandon Redux. The Context API doesn't provide any of this.

And I personally believe that the Redux DevTools extension is an amazing, underestimated debugging tool, which justifies by itself to keep using Redux.

Some references:

Related Query

More Query from same tag