React Context vs React Redux, when should I use ea

Question

React 16.3.0 was released and the Context API is not an experimental feature anymore. Dan Abramov (the creator of Redux) wrote a good comment here about this, but it was 2 years when Context was still an Experimental feature.

My question is, in your opinion/experience when should I use React Context over React Redux and vice versa?

Answer 1

As Context is no longer an experimental feature and you can use Context in your application directly and 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 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 upto 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 component, however application 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 like redux-persist which allow you to save store data in localStorage and rehydrate on refresh which is what context API still doesn't support.

As @dan_abramov mentioned in his blog You might not need Redux, that redux has useful application 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, a la 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 application its far too soon to say that Redux will be replaced by the new Context API

Answer 2

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.

Answer 3

• 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?

Answer 4

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 the logic of your app outside of your components, keeping a state updates history, using Redux DevTools, Redux Undo, Redux Persist, Redux Form, Redux Saga, Redux Logger, etc…), then there is absolutely no reason for you to replace Redux with the Context API.

References:

• Redux Is Not Dead Yet!
• You Might Not Need Redux

Answer 5

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.