React Context vs React Redux,我应该何时使用每一个?

时间:2022-09-10 22:58:17

React 16.3.0 was released and the Context API is not an experimental feature anymore. Dan Abramov (the creator of Redux) wrote a good comment here about this, but it was 2 years when Context was still an Experimental feature.

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

My question is, in your opinion/experience when should I use React Context over React Redux and vice versa?

我的问题是,在您的意见/经验中何时应该使用React Context而不是React Redux,反之亦然?

4 个解决方案

#1


79  

As Context is no longer an experimental feature and you can use Context in your application directly and is going to be great for passing down data to deeply nested components which what it was designed for.

由于Context不再是一个实验性功能,您可以直接在应用程序中使用Context,并且非常适合将数据传递给深度嵌套的组件,而这些组件就是为其设计的。

As Mark erikson has written in his blog:

正如Mark erikson在他的博客中写道:

If you're only using Redux to avoid passing down props, context could replace Redux - but then you probably didn't need Redux in the first place.

如果你只是使用Redux来避免传递道具,那么上下文可以取代Redux - 但是你可能首先不需要Redux。

Context also doesn't give you anything like the Redux DevTools, the ability to trace your state updates, middleware to add centralized application logic, and other powerful capabilities that Redux enables.

Context还没有提供类似Redux DevTools,跟踪状态更新的能力,添加集中式应用程序逻辑的中间件以及Redux支持的其他强大功能。

Redux is much more powerful and provides a large number of features that the Context Api doesn't provide, also as As @danAbramov mentioned

Redux功能更强大,并提供了Context Api不提供的大量功能,正如As @danAbramov所提到的那样

React Redux uses context internally but it doesn’t expose this fact in the public API. So you should feel much safer using context via React Redux than directly because if it changes, the burden of updating the code will be on React Redux and not you.

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

Its upto Redux to actually update its implementation to adhere with the latest context API

它的Redux实际更新其实现以遵守最新的上下文API

The latest Context API can be used for Applications where you would simply be using Redux to pass data between component, however application which use centralised data and handle API request in Action creators using redux-thunk or redux-saga still would need redux. Apart from this redux has other libraries associated like redux-persist which allow you to save store data in localStorage and rehydrate on refresh which is what context API still doesn't support.

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

As @dan_abramov mentioned in his blog You might not need Redux, that redux has useful application like

正如@dan_abramov在他的博客中提到的那样,你可能不需要Redux,那个redux有很多有用的应用程序

  • Persist state to a local storage and then boot up from it, out of the box.
  • 将状态保持到本地存储,然后从开箱即用启动。
  • Pre-fill state on the server, send it to the client in HTML, and boot up from it, out of the box.
  • 在服务器上预填充状态,以HTML格式将其发送到客户端,并从中启动,开箱即用。
  • Serialize user actions and attach them, together with a state snapshot, to automated bug reports, so that the product developers
    can replay them to reproduce the errors.
  • 序列化用户操作并将它们与状态快照一起附加到自动错误报告中,以便产品开发人员可以重放它们以重现错误。
  • Pass action objects over the network to implement collaborative environments without dramatic changes to how the code is written.
  • 通过网络传递操作对象以实现协作环境,而不会对代码的编写方式进行重大更改。
  • Maintain an undo history or implement optimistic mutations without dramatic changes to how the code is written.
  • 维护撤消历史记录或实施乐观突变,而不会对代码的编写方式进行重大更改。
  • Travel between the state history in development, and re-evaluate the current state from the action history when the code changes, a la TDD.
  • 在状态发展之间旅行,并在代码改变时从行动历史中重新评估当前状态,即TDD。
  • Provide full inspection and control capabilities to the development tooling so that product developers can build custom tools for their
    apps.
  • 为开发工具提供全面的检查和控制功能,以便产品开发人员可以为他们的应用程序构建自定义工具。
  • Provide alternative UIs while reusing most of the business logic.
  • 在重用大多数业务逻辑的同时提供备用UI。

With these many application its far too soon to say that Redux will be replaced by the new Context API

有了这么多应用程序,很快就会说Redux将被新的Context API取代

#2


28  

If you are using Redux only to avoid passing props down to deeply nested components, then you could replace Redux with the Context API. It is exactly intended for this use case.

如果您仅使用Redux来避免将props传递给深层嵌套的组件,那么您可以使用Context API替换Redux。它完全适用于此用例。

On the other hand, if you are using Redux for everything else (having a predictable state container, handling the logic of your app outside of your components, keeping a state updates history, using Redux DevTools, Redux Undo, Redux Persist, Redux Form, Redux Saga, Redux Logger, etc…), then there is absolutely no reason for you to replace Redux with the Context API.

另一方面,如果您将Redux用于其他一切(具有可预测的状态容器,在组件外部处理应用程序的逻辑,保持状态更新历史记录,使用Redux DevTools,Redux Undo,Redux Persist,Redux Form, Redux Saga,Redux Logger等...),那么你绝对没有理由用Context API替换Redux。

References:

参考文献:

#3


4  

I prefer using redux with redux-thunk for making API calls (also using Axios) and dispatching the response to reducers. It is clean and easy to understand.

我更喜欢使用redux和redux-thunk进行API调用(也使用Axios)并将响应调度到reducer。它干净,易于理解。

Context API is very specific to the react-redux part on how React components are connected to the store. For this, react-redux is good. But if you want to, since Context is officially supported, you could use the Context API instead of react-redux.

Context API特别针对React组件连接到商店的react-redux部分。为此,react-redux是好的。但是如果你愿意,因为Context是官方支持的,你可以使用Context API而不是react-redux。

So, the question should be Context API vs react-redux, and not Context API vs redux. Also, the question is slightly opinionated. Since, I am familiar with react-redux and use it in all projects, I will continue to use it. (There is no incentive for me to change).

因此,问题应该是Context API vs react-redux,而不是Context API vs redux。此外,这个问题有点自以为是。因为我熟悉react-redux并在所有项目中使用它,我将继续使用它。 (没有动力让我改变)。

But if you are learning redux just today, and you have not used it anywhere, it is worth giving Context API a shot and replace react-redux with your custom Context API code. Maybe, it is much cleaner that way.

但是如果你刚刚学习redux,并且你没有在任何地方使用它,那么值得给Context API一个镜头,并用你的自定义Context API代码替换react-redux。也许,这样更清洁。

Personally, it is a question of familiarity. There is no clear reason to choose one over the other because they are equivalent. And internally, react-redux uses Context anyways.

就个人而言,这是一个熟悉的问题。没有明确的理由选择一个而不是另一个,因为它们是等价的。而在内部,react-redux反正使用Context。

#4


1  

The only reasons to use Redux for me are:

使用Redux的唯一原因是:

  • 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.

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

#1


79  

As Context is no longer an experimental feature and you can use Context in your application directly and is going to be great for passing down data to deeply nested components which what it was designed for.

由于Context不再是一个实验性功能,您可以直接在应用程序中使用Context,并且非常适合将数据传递给深度嵌套的组件,而这些组件就是为其设计的。

As Mark erikson has written in his blog:

正如Mark erikson在他的博客中写道:

If you're only using Redux to avoid passing down props, context could replace Redux - but then you probably didn't need Redux in the first place.

如果你只是使用Redux来避免传递道具,那么上下文可以取代Redux - 但是你可能首先不需要Redux。

Context also doesn't give you anything like the Redux DevTools, the ability to trace your state updates, middleware to add centralized application logic, and other powerful capabilities that Redux enables.

Context还没有提供类似Redux DevTools,跟踪状态更新的能力,添加集中式应用程序逻辑的中间件以及Redux支持的其他强大功能。

Redux is much more powerful and provides a large number of features that the Context Api doesn't provide, also as As @danAbramov mentioned

Redux功能更强大,并提供了Context Api不提供的大量功能,正如As @danAbramov所提到的那样

React Redux uses context internally but it doesn’t expose this fact in the public API. So you should feel much safer using context via React Redux than directly because if it changes, the burden of updating the code will be on React Redux and not you.

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

Its upto Redux to actually update its implementation to adhere with the latest context API

它的Redux实际更新其实现以遵守最新的上下文API

The latest Context API can be used for Applications where you would simply be using Redux to pass data between component, however application which use centralised data and handle API request in Action creators using redux-thunk or redux-saga still would need redux. Apart from this redux has other libraries associated like redux-persist which allow you to save store data in localStorage and rehydrate on refresh which is what context API still doesn't support.

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

As @dan_abramov mentioned in his blog You might not need Redux, that redux has useful application like

正如@dan_abramov在他的博客中提到的那样,你可能不需要Redux,那个redux有很多有用的应用程序

  • Persist state to a local storage and then boot up from it, out of the box.
  • 将状态保持到本地存储,然后从开箱即用启动。
  • Pre-fill state on the server, send it to the client in HTML, and boot up from it, out of the box.
  • 在服务器上预填充状态,以HTML格式将其发送到客户端,并从中启动,开箱即用。
  • Serialize user actions and attach them, together with a state snapshot, to automated bug reports, so that the product developers
    can replay them to reproduce the errors.
  • 序列化用户操作并将它们与状态快照一起附加到自动错误报告中,以便产品开发人员可以重放它们以重现错误。
  • Pass action objects over the network to implement collaborative environments without dramatic changes to how the code is written.
  • 通过网络传递操作对象以实现协作环境,而不会对代码的编写方式进行重大更改。
  • Maintain an undo history or implement optimistic mutations without dramatic changes to how the code is written.
  • 维护撤消历史记录或实施乐观突变,而不会对代码的编写方式进行重大更改。
  • Travel between the state history in development, and re-evaluate the current state from the action history when the code changes, a la TDD.
  • 在状态发展之间旅行,并在代码改变时从行动历史中重新评估当前状态,即TDD。
  • Provide full inspection and control capabilities to the development tooling so that product developers can build custom tools for their
    apps.
  • 为开发工具提供全面的检查和控制功能,以便产品开发人员可以为他们的应用程序构建自定义工具。
  • Provide alternative UIs while reusing most of the business logic.
  • 在重用大多数业务逻辑的同时提供备用UI。

With these many application its far too soon to say that Redux will be replaced by the new Context API

有了这么多应用程序,很快就会说Redux将被新的Context API取代

#2


28  

If you are using Redux only to avoid passing props down to deeply nested components, then you could replace Redux with the Context API. It is exactly intended for this use case.

如果您仅使用Redux来避免将props传递给深层嵌套的组件,那么您可以使用Context API替换Redux。它完全适用于此用例。

On the other hand, if you are using Redux for everything else (having a predictable state container, handling the logic of your app outside of your components, keeping a state updates history, using Redux DevTools, Redux Undo, Redux Persist, Redux Form, Redux Saga, Redux Logger, etc…), then there is absolutely no reason for you to replace Redux with the Context API.

另一方面,如果您将Redux用于其他一切(具有可预测的状态容器,在组件外部处理应用程序的逻辑,保持状态更新历史记录,使用Redux DevTools,Redux Undo,Redux Persist,Redux Form, Redux Saga,Redux Logger等...),那么你绝对没有理由用Context API替换Redux。

References:

参考文献:

#3


4  

I prefer using redux with redux-thunk for making API calls (also using Axios) and dispatching the response to reducers. It is clean and easy to understand.

我更喜欢使用redux和redux-thunk进行API调用(也使用Axios)并将响应调度到reducer。它干净,易于理解。

Context API is very specific to the react-redux part on how React components are connected to the store. For this, react-redux is good. But if you want to, since Context is officially supported, you could use the Context API instead of react-redux.

Context API特别针对React组件连接到商店的react-redux部分。为此,react-redux是好的。但是如果你愿意,因为Context是官方支持的,你可以使用Context API而不是react-redux。

So, the question should be Context API vs react-redux, and not Context API vs redux. Also, the question is slightly opinionated. Since, I am familiar with react-redux and use it in all projects, I will continue to use it. (There is no incentive for me to change).

因此,问题应该是Context API vs react-redux,而不是Context API vs redux。此外,这个问题有点自以为是。因为我熟悉react-redux并在所有项目中使用它,我将继续使用它。 (没有动力让我改变)。

But if you are learning redux just today, and you have not used it anywhere, it is worth giving Context API a shot and replace react-redux with your custom Context API code. Maybe, it is much cleaner that way.

但是如果你刚刚学习redux,并且你没有在任何地方使用它,那么值得给Context API一个镜头,并用你的自定义Context API代码替换react-redux。也许,这样更清洁。

Personally, it is a question of familiarity. There is no clear reason to choose one over the other because they are equivalent. And internally, react-redux uses Context anyways.

就个人而言,这是一个熟悉的问题。没有明确的理由选择一个而不是另一个,因为它们是等价的。而在内部,react-redux反正使用Context。

#4


1  

The only reasons to use Redux for me are:

使用Redux的唯一原因是:

  • 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.

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