React 16.3.0 已发布，Context API 不再是实验性功能。Dan Abramov（Redux 的创建者）在这里写了一篇很好的评论，但是 Context 仍然是一个实验性功能已经 2 年了。
我的问题是，根据您的意见/经验，我什么时候应该使用React Context 而不是React Redux，反之亦然？
React Context 与 React Redux，我应该什么时候使用它们？
IT技术
javascript
reactjs
redux
react-redux
react-context
2021-01-31 08:04:42
5个回答
由于Context不再是一个实验性功能，您可以直接在您的应用程序中使用 Context，它将非常适合将数据传递给它设计用于深度嵌套的组件。
正如 Mark Erikson 在他的博客中所写：
如果您只是使用 Redux 来避免传递 props，则上下文可以替换 Redux - 但是您可能一开始就不需要 Redux。
Context 也没有为您提供诸如
Redux DevTools跟踪状态更新的能力、middleware添加集中式应用程序逻辑以及其他强大的功能Redux。
Redux更强大，并提供了大量Context API不提供的功能，正如@danAbramov 所提到的
React Redux 在内部使用上下文，但它没有在公共 API 中公开这个事实。所以你应该觉得通过 React Redux 使用上下文比直接使用上下文要安全得多，因为如果它发生变化，更新代码的负担将落在 React Redux 而不是你身上。
实际更新其实现以符合最新的 Context API 取决于 Redux。
最新的 Context API 可用于应用程序，您只需使用 Redux 在组件之间传递数据，但是使用集中数据并在 Action creators 中处理 API 请求的应用程序使用redux-thunk或redux-saga仍然需要 Redux。除此之外，Redux 还有其他与之相关的库，例如redux-persist允许您在 localStorage 中保存/存储数据并在刷新时重新水合，而 Context API 仍然不支持。
正如@dan_abramov 在他的博客中提到的你可能不需要 Redux，Redux 有一些有用的应用程序，比如
- 将状态持久化到本地存储，然后从它启动，开箱即用。
- 在服务器上预填充状态，将它以 HTML 格式发送到客户端，然后从它启动，开箱即用。
- 序列化用户操作并将它们与状态快照一起附加到自动错误报告中，以便产品开发人员
可以重放它们以重现错误。- 通过网络传递动作对象以实现协作环境，而无需对代码的编写方式进行重大更改。
- 维护撤消历史记录或实现乐观突变，而无需对代码的编写方式进行重大更改。
- 在开发中的状态历史之间穿梭，并在代码更改时从动作历史中重新评估当前状态，ala TDD。
- 为开发工具提供完整的检查和控制功能，以便产品开发人员可以为其应用程序构建自定义工具。
- 在重用大部分业务逻辑的同时提供替代 UI。
有了这么多应用程序，现在说 Redux 将被新的 Context API 取代还为时过早。
如果您使用 Redux 只是为了避免将 props 传递给深层嵌套的组件，那么您可以用ContextAPI替换 Redux 。它完全适用于这个用例。
另一方面，如果您将 Redux 用于其他一切（具有可预测的状态容器，在组件之外处理应用程序的逻辑，集中应用程序的状态，使用Redux DevTools跟踪应用程序的状态何时、何地、为什么以及如何更改，或者使用Redux Form、Redux Saga、Redux Undo、Redux Persist、Redux Logger等插件...），那么你绝对没有理由放弃 Redux。该ContextAPI不提供任何这一点。
而且我个人认为Redux DevTools 扩展是一个了不起的、被低估的调试工具，它本身就有理由继续使用 Redux。
一些参考：
我更喜欢使用 redux 和 redux-thunk 进行 API 调用（也使用 Axios）并将响应分派给 reducer。它干净且易于理解。
Context API 非常特定于关于 React 组件如何连接到 store 的 react-redux 部分。为此，react-redux 很好。但是如果你愿意，因为官方支持 Context，你可以使用 Context API 而不是 react-redux。
所以，问题应该是 Context API vs react-redux，而不是 Context API vs redux。另外，这个问题有点自以为是。因为，我熟悉 react-redux 并在所有项目中使用它，我将继续使用它。（我没有动力去改变）。
但是如果你刚刚在学习 redux，而且你还没有在任何地方使用过它，那么给 Context API 一个机会并用你自定义的 Context API 代码替换 react-redux 是值得的。也许，那样会干净得多。
就个人而言，这是一个熟悉程度的问题。没有明确的理由选择一个而不是另一个，因为它们是等效的。在内部，react-redux 无论如何都使用 Context。
对我来说使用 Redux 的唯一原因是：
- 您需要一个全局状态对象（出于各种原因，例如可调试性、持久性...）
- 您的应用程序已经或将会很大，并且应该扩展到许多开发人员：在这种情况下，您可能需要一个间接级别（即事件系统）：您触发事件（过去），然后触发您不认识的人组织实际上可以听取他们的意见
您可能不需要整个应用程序的间接级别，因此可以混合样式并同时使用本地状态/上下文和 Redux。
- 如果您需要将中间件用于各种目的。例如记录操作、错误报告、根据服务器的响应调度其他请求等。
- 当来自多个端点的数据影响单个组件/视图时。
- 当您想要更好地控制应用程序中的操作时。Redux 启用跟踪操作和数据更改，它大大简化了调试。
- 如果您不希望服务器响应直接更改应用程序的状态。Redux 添加了一个层，您可以在其中决定如何、何时以及是否应用这些数据。观察者模式。您只需将组件连接到 Redux 商店，而不是在整个应用程序中创建多个发布者和订阅者。