1

在阅读了有关上下文的官方文档（https://reactjs.org/docs/context.html）之后，我觉得它的使用应该主要限于当我们有一些我们可以考虑“全局”的变量的情况下，我们必须发送到不同嵌套级别的许多组件（如当前主题、语言环境、当前经过身份验证的用户）。

Context 旨在共享可被视为 React 组件树“全局”的数据，例如当前经过身份验证的用户、主题或首选语言。

和

上下文主要用于在不同嵌套级别的许多组件需要访问某些数据时。谨慎应用它，因为它使组件重用更加困难。

我想使用 Context 来促进组件树中彼此相距较远的组件之间的通信。许多用户为此使用了 Redux（尽管这不是它的主要目的），这并没有同样令人沮丧，即使与 React 一起使用（通过 react-redux 包）这种方法在内部由 Context 提供支持。

Context 与 redux + react-redux 相比有什么缺点（除非 Redux 有不同的更新状态的方式），这应该让我在所描述的场景中不使用 Context 吗？文档说它使组件重用变得更加困难。它是如何做到的，这个 con 不是也与 redux + react-redux duo 有关吗？

4

2 回答 2

3

不气馁，可用于不同嵌套级别的组件通信。

Context 与 redux + react-redux 相比有什么缺点（除非 Redux 有不同的更新状态的方式），这应该让我在所描述的场景中不使用 Context 吗？文档说它使组件重用变得更加困难。

React 上下文可能不太方便调试，因为它目前无法使用 Redux 开发工具。有一个可以观察的问题，但是任何可能的解决方案都不能涵盖通过上下文 API 进行的交互，这些交互是使用回调函数执行的，例如这个模态示例，而调度的 Redux 操作可以被跟踪。

文档没有解释为什么它很难重用，“难”是主观的。Provider依赖于上下文的组件对组件层次结构中的各个组件施加隐藏的依赖。它与它松散耦合，但如果没有预期的提供值，它可能会出现故障；如果没有Provider,Consumer仍然用undefined值呈现，则在没有手动值验证的情况下无法更改此行为。

于 2018-10-03T09:57:11.963 回答
0

我对你的问题不够清楚。但是考虑到您所说的 react docs 的声明，

上下文主要用于在不同嵌套级别的许多组件需要访问某些数据时。谨慎应用它，因为它使组件重用更加困难。

我可以从文档中看到一个警告：您可能需要提升状态。

在你的项目中使用 context api 之前需要考虑一些事情，如果你不这样做，你可能会失败。我认为这是因为您可以记住“谨慎应用它，因为它使组件重用变得更加困难”这一说法。文档中概述了以下几点，您可以如何使用上下文 api，可以考虑将组件重新用于各种需要：

你可能会明显感觉到困难。否则，我可以看到，它可以用于我们可以用 redux 做的事情，除了 redux 记录器。

于 2018-10-03T09:54:49.013 回答