When To Use Redux And When Stick To The Context API?
Reading Time: 3 minutes
The complaint that is often voiced by inexperiencedReact developers, is that Redux actually complicates their work instead of simplifying it. This is understandable – this tool was invented for managing data flow in more complex applications and seems to be an overkill for simple SPAs or websites.
The problems with learning Redux:
- Developers don’t always get the chance to work in a big project without Redux, they are introduced to this technology simultaneously as they start using React. Therefore, they can’t see which problems Redux was invented to solve (no pain – no gain ), what are the alternatives and why they are more efficient/convenient
- Redux tutorials usually involve building simple apps/features that could be easily done in Vanilla JS. That’s why the first impression that programmers can get is confusion about the tool’s purpose.
A good example of a course that teaches less trivial material and explains Redux well is “ Advanced React and Redux: 2018 Edition” by Stephen Grider.
Which problems does Redux solve?
Separating “what happened” from “what you need to do”
This is not obvious. If application repeats the pattern “component has rendered and needs fetching data from API to render children/list elements”, we will just repeat calling REQUEST and RECEIVE actions, with nothing in between – that’s a redundancy which can be replaced by simple asynchronous calls. Even if you need Redux in your app, repeating the same pattern in multiple reducers is considered to be a bad practice. You can replace it with simpler reducer and reuse it (adding a parameter, like paramName).
Passing props through multiple components that don’t use it
This problem is called “prop drilling”. Those props just add extra lines of code in components. However, you can solve this problem by Context or by changing component composition.
In the example above data object can be accessed by multiple components without the need for passing it through intermediate components (here, ComponentWrapper).
Passing callbacks up through components that don’t need it
The same problem as with props (callbacks are props too), but data passes in a different direction – that seems like contrary to the concept of React (since React renders top down).
When to use Redux
Even Redux creators and contributors will tell you that you should use Redux implicitly. After thinking about your app’s architecture thoroughly, you might consider using these tool in the following cases:
- 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.
When Redux is an overkill and Context API is enough?
If you haven’t yet used Context API (the new version of it was introduced in React 16.3, the previous API was introduced rather on experimental basis and developers were discouraged from using it directly in apps), you might give it a try in some instances, when you don’t use most of the opportunities Redux offers. Here are conditions where Context could be adequate:
- State management accessible from every component. This is not enough of a reason to use Redux, which introduces too much abstraction for such purpose.
- No middleware is necessary. Reducers perform simple predictable action and the order of received data is irrelevant for the application.
- You need something like global data (“theme” is an example I see often while inspecting apps through DevTools).
Redux is a great tool for those, who truly understand it and use it when the code architecture demands such a solution. Currently, developers can face challenges in maintaining legacy code that is overcomplicated and confusing. Replacing Redux Store with React’s Context is a suggestion that React developers can consider while refactoring.
We are Ideamotive – custom web development company. We create state-of-the-art web applications with the top quality code. Looking for heroes to help you with your next venture?Drop us a line!
- 在react redux的技术栈中优雅的使用异步
- 带着问题看 react-redux 源码实现
- react 项目集成 react-redux 解决 state 存储与共享问题
- 前端 api 请求缓存方案
- 优雅的redux异步中间件 redux-effect
- rrh - Simple and Easy React Hooks for react-redux.
- 闲鱼 fish-redux 的非官方可视化调试工具
- 我终于被 implementation 和 api 逼疯了
- swagger api文档集中化注册管理
- springfox-bridge：随心所欲地为非restful接口生成swagger api文档
- omni api速查手册
- 前端 api 请求缓存方案
- 十分钟上线-基于函数计算开发asp.net core web app & restful web api
- kubernetes 客户端KubeClient使用及常用api
- Mithril-hooks: React hooks api for MithrilJs by ArthurClemens
- 性能优化篇 - Performance（工具 & api）