React Context vs React Redux，我应该什么时候使用它们？ [关闭]答案

【问题标题】：React Context vs React Redux, when should I use each one? [closed]React Context vs React Redux，我应该什么时候使用它们？ [关闭]
【发布时间】：2018-09-09 02:53:00
【问题描述】：

React 16.3.0 was released 和 Context API 不再是实验性功能。 Dan Abramov（Redux 的创建者）为此写了一篇很好的评论 here，但是 Context 仍然是一个实验性功能已经 2 年了。

我的问题是，根据您的意见/经验，我应该在什么时候使用 React Context 而不是 React Redux，反之亦然？

【问题讨论】：

如果你在比较 Redux 和 React Context API，那是因为你只想在组件之间保持 vars 的同步。检查duix npm 包。它只是一个带有回调的简单状态管理器，非常容易实现。明确一点：我是创造者。

标签： javascript reactjs redux react-redux react-context

【解决方案1】：

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

正如 Mark Erikson 在他的 blog 中所写：

如果你只是使用 Redux 来避免传递 props，上下文可以替换 Redux - 但你可能一开始就不需要 Redux 地点。

上下文也不会给你任何像Redux DevTools，跟踪您的状态更新的能力，middleware 添加集中式应用程序逻辑，以及Redux 的其他强大功能启用。

Redux 功能更强大，并提供了大量 Context API 不提供的功能，正如 @danAbramov 提到的

React Redux 在内部使用上下文，但它没有在公共 API。所以你应该通过 React 使用 context 感觉更安全 Redux 比直接因为如果它改变了，更新的负担代码将在 React Redux 而不是你。

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

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

正如@dan_abramov 在他的博客You might not need Redux 中提到的，Redux 有一些有用的应用程序，例如

将状态保存到本地存储，然后从它启动，开箱即用。

在服务器上预填充状态，以 HTML 格式发送到客户端，然后从它启动，开箱即用。

序列化用户操作并将它们与状态快照一起附加到自动错误报告中，以便产品开发人员
可以重放它们以重现错误。

通过网络传递操作对象以实现协作环境，而无需对代码的编写方式进行重大更改。

维护撤消历史记录或实施乐观突变，而无需对代码的编写方式进行重大更改。

在开发中的状态历史之间穿梭，并在代码更改时从动作历史中重新评估当前状态，例如 TDD。

为开发工具提供全面的检查和控制功能，以便产品开发人员可以为其应用构建自定义工具。

在重用大部分业务逻辑的同时提供替代 UI。

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

【讨论】：

好的，但是可重用性呢？上下文是完全可重用的，一旦 redux + thunk，尤其是 redux + saga 几乎没有。
@Daggett 我们需要了解的一点是redux不是上下文，它建立在上下文之上，你拥有的商店是通过上下文传递的，你能否详细说明你所说的可重用性
即使是开发这样一个基本的东西，比如带有副作用的可重用容器，也变成了 redux 的噩梦。 Redux 与应用程序级别紧密相关，您可能会说，它仍然是可重用的等等，但说可重用是指完全可重用......没有尖峰的意大利面条，构建为单独的包，并且可以独立地重用应用程序设置.
@YuriiHaiovyi 我同意你的问题。这个答案基本上是链接博客文章所说的编译版本。没有什么要分享自己的观点，就像 我一直只使用上下文，然后我被卡住了，觉得出于某些 x、y、z 原因，这是一个糟糕的选择，然后转移到 Redux，Mobx 解决了它。或相反的故事 例如。主要是人们在询问或搜索这个，看看是否有一些故事是好是坏，这可以帮助读者思考并做出有计划的决定......所以我的问题是你选择什么路径？
redux 的哪一部分不可复用？您可以轻松地在另一个应用程序中使用 redux（react，甚至 angular）重用 reducer、选择器、动作和动作创建者。

【解决方案2】：

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

另一方面，如果您将 Redux 用于其他一切（拥有可预测的状态容器，在组件之外处理应用程序的逻辑，集中应用程序的状态，使用 Redux DevTools 跟踪您的应用程序状态何时、何地、为什么以及如何改变，或者使用诸如Redux Form、Redux Saga、Redux Undo、Redux Persist、Redux Logger 等插件，那么您绝对没有理由放弃 Redux。 Context API 不提供任何这些。

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

一些参考资料：

【讨论】：

【解决方案3】：

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

上下文 API 非常特定于 react-redux 部分，关于 React 组件如何连接到商店。为此，react-redux 很好。但如果你愿意，既然官方支持 Context，你可以使用 Context API 代替 react-redux。

所以，问题应该是 Context API vs react-redux，而不是 Context API vs redux。另外，这个问题有点自以为是。由于我对 react-redux 很熟悉，并且在所有项目中都会用到它，所以我会继续使用它。（我没有改变的动力）。

但是如果你今天才在学习 redux，而且你还没有在任何地方使用过它，那么值得试一试 Context API 并将 react-redux 替换为你自定义的 Context API 代码。也许，这样更干净。

就个人而言，这是一个熟悉程度的问题。没有明确的理由选择其中之一，因为它们是等价的。在内部，react-redux 无论如何都使用 Context。

【讨论】：

【解决方案4】：

我使用 Redux 的唯一原因是：

您需要一个全局状态对象（出于各种原因，例如可调试性、持久性...）
您的应用程序已经或将会很大，并且应该扩展到许多开发人员：在这种情况下，您可能需要一定程度的间接性（即事件系统）：您（过去）触发事件，然后触发您不触发的人知道在您的组织中实际上可以倾听他们的意见

您可能不需要整个应用程序的间接级别，因此可以混合样式并同时使用本地状态/上下文和 Redux。

【讨论】：

【解决方案5】：

如果您需要将中间件用于各种目的。 例如记录操作、错误报告、调度其他请求，具体取决于服务器的响应等。

当来自多个端点的数据影响单个组件/视图时。

如果您希望更好地控制应用程序中的操作。 Redux 支持跟踪操作和数据更改，它大大简化了调试。

如果您不希望服务器响应直接更改应用程序的状态。 Redux 添加了一个层，您可以在其中决定如何、何时以及是否应应用此数据。观察者模式。代替在整个应用程序中创建多个发布者和订阅者，您只需将组件连接到 Redux 存储即可。

发件人：When to use Redux?

【讨论】：