Zustand 和 Recoil 性能之间的概念差异是什么

Question

我一直在研究Zustand和Recoil——两个相对较新的状态管理库。

Recoil 被大力宣传为具有深度嵌套结构的 React 应用程序“非常高性能”。然而，我不知道它如何（或究竟如何）在性能方面优于 Zustand（除了并发模式）。

我可能会弄错，但这是我从文章和演讲中理解的：“为什么”Recoil 具有高性能的主要原因是您所做的任何更新只会触发相关组件重新渲染，而不会影响任何其他组件。Recoil 在设计上允许它并且开箱即用，而基于上下文的库必须通过整个树传递每个更改，对这些更改进行比较/协调，然后可能只重新渲染必须更改的内容。

现在，Zustand 根本不使用 Context API。因此，我假设（除了并发模式），它具有与 Recoil 相当的性能优势，其中 Zustand 只会“接触”相关组件，而不会通过整个组件树传递更改。

如果我的理解有误，请告诉我。这两个库在性能上是否具有可比性（没有并发模式）？或者，Recoil 的原子范式是否存在其他一些固有属性，使其在理论上具有优越的性能？

请注意：我希望答案不要过多地受到模式和实践的影响。我理解，有时范式的最大好处可能在于“它强制执行的健全模式”，但我感兴趣的不是它们强制执行的内容，而是它们允许通过类似的努力来做什么。例如，我知道平坦的标准化状态将允许 Zustand 获得更好的性能，并且 Zustand 不一定“强迫您以适当/可扩展的方式进行操作”。但我不希望正确模式的“可选性”成为一个缺点。

Answer 1

它们都有各自的优点和缺点，这意味着您应该根据您的项目要求进行选择。例如：

使用React 的内部Context API，Recoil 在内部使用此 API 将状态更新传播到订阅的组件，但是，Zustand使用 React 的自定义基于钩子的方法来处理组件状态分发。因此，即使Recoil在上下文边界内优化组件，您仍然会产生一些性能开销。

Zustand的目标是尽最大努力减少与React协调过程相关的开销，这样我们就可以放心，我们的 UI 将保持与应用程序状态的同步，同时最大限度地减少不必要的重新渲染并优化性能。

如果您有一个相当复杂的深度嵌套组件的应用程序树，Recoil使用原子和选择器模式，使您可以定义细粒度的组件依赖关系，因此当特定原子更改时，只有依赖于该原子的组件会被重新定义。呈现。也就是说，如果您的目标是优化组件的重新渲染，那么您绝对应该考虑 Recoil 作为解决方案。

取决于您想要如何操纵数据流，即读/写。如果您正在寻找类似于Redux 的单向数据流，您应该考虑Recoil。

如果您更喜欢Zustand更直接的方法，您的状态将存储在单个存储中，并由您的组件直接访问和修改。