An experiment with React Context API, is it better than Redux?

While experimenting with React applications, we often came across situations where data needs to be accessible by many components at different nesting levels. Initially our approach was to pass data top-down through props from parent to child. Then we started another way to handle sharing data with the use of store. A store holds the whole state tree of your application, then Redux , a state management library comes into the picture.

Redux can be used with AngularJS (NgRx) apart from React. First check what Redux offers :

1. A single, centralized state (i.e. a global JS object) in store.
2. Reducer functions that contain the logic to change and update the global state
3. Actions that can be dispatched to trigger a reducer function to run
4. Subscriptions to get data out of the global state (e.g. to use it in React components)-

• connect method is used to set up a subscription- it lets you pass global state to any component in application without manually passing that data via props.

connect(mapStateToProps, mapDispatchToProps)(sampleComponent)

Redux was introduced in 2015, its <Provider> component has always used React's Context API internally. This React context API is one of the major forces behind the most useful packages in the React ecosystem. Starting with React 16.3 released in 2018, the official React Context API hits the ground, it involves the use of two special components: <Provider> and <Consumer>.

So lets check what Context offers:

1. Context lets you “broadcast” the data, and changes to it, to all components below- ie. the provider of the context sets some data and then all the descendants of the component tree which are consumer of the context can access the data.
2. It also allows to get data into a single component from 2 different providers /from 2 different context instances/from 2 different part of application.

In contrast, Redux provides a whole toolkit for managing state which context does not support:

• It comes with a time traveling debugger
• It provides a middleware API, giving you access to tools like redux-sagas
• Its React bindings prevent many unnecessary renders

Then what is the point using Context API?

what if we don’t want middleware support or time traveling debugging? then should we use Redux or Context API. So here comes some other advantages of React’s new Context API, it always propagates updates, even past shouldComponentUpdate() or PureComponent.

With React’s old context API, React decided whether to re-render a child solely based on the component’s props and state. It didn’t take changes in context into account. This meant that if a component extended PureComponent or it implemented shouldComponentUpdate, the context in the component and its children would sometimes get out of date.

The new <Context.Consumer> component will always re-render after its corresponding <Context.Provider> element’s value prop has been updated - even if there is a PureComponent or shouldComponentUpdate() in the way.

Having a sample example here. Let’s say I want to order a mobile phone from Amazon and I liked the mobile cover which is available at Myntra. So how can I use context API here? And as I am a valuable customer of both the organization they want me to deliver first rather than the other customers who ordered ahead of me. These other customers are the middleware components between me and the organizations. So I will get my orders without passing through props via other customers.

context.js:

So it is a much more flexible way to handle properties via context.

So, in a nutshell, Context is already available with React library and does not need any other library, a little more efficient and little more lighter code, uses minimal set up. Sometimes it works as a global variable and you need to choose wisely whether to use this or redux.