In JSconf 2018, the former Redux head, Dan Abramov, announced a small tool that he built to simplify data fetching and state management. It was called the future-fetcher/React Context API.
Redux, so far, is one of the most popular state management tools that is used widely with React. Even Angular users are quite fond of it. Vue also has a provision for using Redux in its ecosystem. However tools like Mobx are also getting enough popularity because of their simplicity and ease of use.
What’s the problem with Redux? The honest answer is that it’s simply too complicated. If we have to understand the real probability of it being replaced by any other tool, then we will have to understand how it works. The workflow is illustrated in the below figure.
Source: Freecodecamp.org
The above image shows how basic Flux architecture functions and Redux is based quite heavily on this architecture model. This can be very complicated for a novice web developer. A beginner level developer might just get overwhelmed with the use of functional programming concepts like ‘creation’, ‘dispatcher’ and ‘Action’ functions and using them in appropriate situations. Redux follows the same application logic and those who are not comfortable with functional programming, might find using Redux quite cumbersome.
That’s where the Future-Fetcher/ Context API comes in. Context API is a production-grade, efficient API that supports things like static type checking and deep updates. In React, different application levels and layers consist of React components and these components have nested relations with each other.
In other words, they are connected to each other like a tree and if one component needs to change its state, and it has to pass on the information to the next component, then it transfers an entity called ‘prop’. The state management is important because you would want your application layers to be consistent with your data, so that when one component changes state, the relevant data has to passed on to the component which will allow it to respond accordingly.
In Redux, you will have to write functions as mentioned above to implement this. But in context API, the architecture looks a bit different than the Redux-Flux architecture and there lies the difference.
Source: Freecodecamp.org
In case of Context API, the need to write functions like Action, Dispatch etc. vanishes, that makes the job of a developer quite easy. Here, we only have ‘view’ and the ‘store’ component, where “Store” contains the dynamic state of the application layers. This simplifies a lot of processes. Although the problem of scaling might be an issue in this particular form of architecture. Still, for normal web applications, where dynamic and real time behavior are important, Context API provides a much easier way of implementation.
Since this feature has been developed by the primary architect of Redux, the developer community is of the opinion that it might face a tough challenge in the days to come. Still it’s early days to say – Game Over Redux.
Read Next
Creating Reusable Generic Modals in React and Redux
