263

React 16.3.0 已发布，Context API 不再是实验性功能。Dan Abramov（Redux 的创建者）在这里写了一个很好的评论，但是 Context 仍然是一个实验性功能已经 2 年了。

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

4

5 回答 5

283

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

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

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

上下文也没有给你任何东西Redux DevTools，比如跟踪你的状态更新的能力，middleware添加集中的应用程序逻辑，以及其他强大的功能Redux 。

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

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

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

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

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

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

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

于 2018-03-30T05:58:26.933 回答
125

如果你使用 Redux 只是为了避免将 props 向下传递给嵌套的组件Context，那么你可以用API替换 Redux 。它正是针对此用例而设计的。

另一方面，如果您将 Redux 用于其他所有事情（拥有可预测的状态容器，在组件之外处理应用程序的逻辑，集中应用程序的状态，使用Redux DevTools来跟踪应用程序的状态的时间、地点、原因和方式）改变了，或者使用了Redux Form、Redux Saga、Redux Undo、Redux Persist、Redux Logger等插件……），那么你绝对没有理由放弃 Redux。ContextAPI 不提供任何这些。

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

一些参考资料：

于 2018-03-30T05:59:58.103 回答
20

我更喜欢使用 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。

于 2018-03-30T06:19:01.480 回答
15

The only reasons to use Redux for me are:

  • You want a global state object (for various reasons, like debuggability, persistence...)
  • Your app is or will be big, and should scale to many developers: in such case you probably need a level of indirection (ie an event system): you fire events (in the past) and then people you don't know in your organisation can actually listen to them

You probably don't need the level of indirection for your whole app, so it's fine to mix styles and use local state/context and Redux both at the same time.

于 2018-05-28T12:59:50.033 回答
6
  • 如果您需要将中间件用于各种目的。例如记录操作、错误报告、根据服务器的响应分派其他请求等。
  • 当来自多个端点的数据影响单个组件/视图时。
  • 当您想要更好地控制应用程序中的操作时。Redux 支持跟踪操作和数据更改，它极大地简化了调试。
  • 如果您不希望服务器响应直接更改应用程序的状态。Redux 添加了一个层，您可以在其中决定如何、何时以及是否应该应用这些数据。观察者模式。无需在整个应用程序中创建多个发布者和订阅者，您只需将组件连接到 Redux 商店。

来自：何时使用 Redux？

于 2018-12-13T11:40:39.363 回答