React Context vs React Redux，我什么时候应该使用每个？[已关闭]

由于 Context 不再是一个实验性功能，您可以直接在应用程序中使用 Context，因此它将非常适合将数据传递到深度嵌套的组件，而这些组件是它所设计的目的。

正如马克·埃里克森（Mark Erikson）在他的博客中写道：

如果你只是使用Redux来避免传递道具，那么上下文可以取代Redux - 但是你可能一开始就不需要Redux。

上下文也不会为您提供类似 的东西，能够跟踪状态更新，添加集中式应用程序逻辑以及其他强大的功能。Redux DevToolsmiddlewareRedux

Redux功能更强大，并提供大量未提供的功能，也如@danAbramov所述Context API

React Redux在内部使用上下文，但它没有在公共API中暴露这一事实。因此，通过 React Redux 使用上下文应该比直接使用上下文更安全，因为如果它发生变化，更新代码的负担将落在 React Redux 上，而不是你身上。

由 Redux 实际更新其实现以遵循最新的 Context API。

最新的 Context API 可用于应用程序，在这些应用程序中，您只需使用 Redux 在组件之间传递数据，但是使用集中式数据并在 Action 创建者中使用或仍然需要 Redux 的应用程序处理 API 请求的应用程序。除此之外，Redux还有其他与之相关的库，例如，它允许您在localStorage中保存/存储数据，并在刷新时重新冻结，这是上下文API仍然不支持的。redux-thunkredux-sagaredux-persist

正如@dan_abramov在他的博客中提到的，你可能不需要Redux，Redux有有用的应用程序，如

• 将状态保存到本地存储，然后开箱即用地从该存储启动。
• 在服务器上预填充状态，以 HTML 格式将其发送到客户端，然后开箱即用地从客户端启动。
• 序列化用户操作并将其与状态快照一起附加到自动 bug 报告中，以便产品开发人员
  可以重播它们以重现错误。
• 通过网络传递操作对象以实现协作环境，而无需对代码的编写方式进行巨大更改。
• 维护撤消历史记录或实现乐观突变，而不会对代码的编写方式进行重大更改。
• 在开发中的状态历史记录之间移动，并在代码更改时重新评估操作历史记录中的当前状态>，ala TDD。
• 为开发工具提供完整的检查和控制功能，以便产品开发人员可以为其应用构建自定义工具。
• 提供备用 UI，同时重用大部分业务逻辑。

有了这么多应用程序，现在说Redux将被新的上下文API所取代还为时过早。

如果你使用 Redux 只是为了避免将 props 传递给深度嵌套的组件，那么你可以用 API 替换 Redux。它完全适用于此用例。Context

另一方面，如果您将 Redux 用于其他所有用途（具有可预测的状态容器，在组件之外处理应用程序的逻辑，集中应用程序的状态，使用 Redux DevTools 跟踪应用程序状态更改的时间、位置、原因和方式，或者使用诸如 Redux Form、Redux Saga、Redux Undo、Redux Persist 等插件， Redux Logger，等等），那么你绝对没有理由放弃Redux。API 不提供任何此类功能。Context

我个人认为，Redux DevTools扩展是一个惊人的，被低估的调试工具，它本身就证明了继续使用Redux是合理的。

一些参考：

• Redux 还没有死！
• 您可能不需要 Redux
• React Hooks 会取代 Redux 吗？