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

React 16.3.0已发布，并且Context API不再是实验功能。Dan Abramov（Redux的创建者）在这里对此发表了很好的评论，但是Context仍然是实验性功能已经有两年了。

我的问题是，根据您的看法/经验，我何时应该在React Redux上使用React Context，反之亦然？

由于Context不再是实验性功能，您可以直接在应用程序中使用Context，这对于将数据传递到为其设计的深层嵌套的组件方面非常有用。

正如Mark erikson在他的博客中所写的：

如果您仅使用Redux来避免传递道具，则上下文可以替换Redux-但是您可能首先不需要Redux。

上下文也不提供Redux DevTools，跟踪状态更新，middleware添加集中式应用程序逻辑以及其他Redux 启用这些功能的功能。

Redux具有更强大的功能，并提供了许多Context Api未提供的功能，正如@danAbramov所提到的

React Redux在内部使用上下文，但未在公共API中公开这一事实。因此，通过React Redux使用上下文比直接使用上下文要安全得多，因为如果上下文发生更改，更新代码的负担将落在React Redux上，而不是您。

它由Redux负责实际更新其实现以符合最新的上下文API

最新的Context API可以用于您将仅使用Redux在组件之间传递数据的应用程序，但是使用集中式数据并在使用redux-thunk或redux-saga仍需要Redux的Action创建者中处理API请求的应用程序。除了此Redux之外，还有其他关联的库，例如redux-persist，它们允许您将存储数据保存在localStorage中并在刷新时重新补水，这是上下文API仍不支持的。

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

• 将状态持久保存到本地存储，然后从中启动，即可使用。
• 在服务器上预填充状态，以HTML格式将其发送到客户端，然后从中启动。
• 序列化用户操作，并将其与状态快照一起附加到自动错误报告，以便产品开发人员
  可以重播它们以重现错误。
• 通过网络传递动作对象以实现协作环境，而无需对代码的编写进行重大更改。
• 保留撤消历史记录或实施乐观的更改，而无需对代码的编写方式进行重大更改。
• 在开发中的状态历史记录之间移动，并在代码更改时从动作历史记录重新评估当前状态（如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
• React Hook可以代替Redux吗？

我更喜欢将redux与redux-thunk一起使用来进行API调用（也使用Axios）并将响应分配给reducer。它很干净而且易于理解。

上下文API专门针对react-redux部分介绍如何将React组件连接到商店。为此，react-redux很好。但是，如果您愿意，由于正式支持Context，则可以使用Context API代替r​​eact-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商店，而不是在整个应用程序中创建多个发布者和订阅者。

来自：何时使用Redux？