为啥 Context API 在高频更新方面比 Redux 差？

Posted 2023-04-14

【中文标题】为啥 Context API 在高频更新方面比 Redux 差？

【英文标题】：Why Context API is worse than Redux for high frequency updates?为什么 Context API 在高频更新方面比 Redux 差？

【发布时间】：2021-07-02 10:35:33

【问题描述】：

我看到很多文章说Redux在性能上比高频更新要好，但没有具体说明原因。

是什么让人们说 Redux 在高频更新方面比 Context API 更好？

【参考方案1】：

我在 Why React Context is Not a "State Management" Tool (and Why It Doesn't Replace Redux)、React, Redux, and Context Behavior 和 The History and Implementation of React-Redux 的帖子中广泛介绍了这一点。

总结：目前，将新值传递给<MyContext.Provider> 会强制每个 订阅该上下文的组件重新渲染。如果组件只关心 Context 值的 part 并且该部分没有改变，则没有办法解决。

此外，React 目前必须做大量工作来循环整个组件树，以确定 哪些 组件订阅了给定的上下文。

另一方面，React-Redux 依赖于对 Redux 存储的直接订阅。它在分派操作时运行您的选择器，并且仅在提取的数据发生更改时强制该组件重新呈现。因此，目前，在大多数情况下，这提供了比 Context 更好的性能，因为对于给定的更改需要重新渲染的组件更少。

React 团队一直在研究“上下文选择器”和“惰性上下文传播”的一些潜在实现，这可能有助于在未来加快速度。目前还没有发布这些内容的时间表。

【讨论】：

感谢您的回答。但是有一点，您说 Context Provider 会在每个组件的一部分发生更改时强制每个组件重新渲染。但是像 Redux 那样，是不是可以把它分成很多个 Context 来使用呢？

是的，您始终可以将事物拆分为许多较小的上下文。正如我的帖子所说，我认为这种方法很难快速维持。 （不，这与 Redux 所做的不相同。）