全局状态管理中三个竞争者的比较
> Photo by Joshua Aragon on Unsplash
随着全局状态管理工作的日新月异，可能很难知道该选择哪个选项。Redux在很长一段时间以来一直是被选择的库，但是由于提供了状态管理的Context API已嵌入到React本身，许多人已经宣布Redux已死。现在，随着Facebook支持的早期项目Recoil的发布，我们有了一个特定于React的库，可以轻松地与React的最新功能集成。
但是哪一个最适合您的项目？在本文中，我将与每个库集成一个简单的应用程序，并提供一些比较和观察。这些只是我的意见-我绝对不会将我的发现作为事实提出，最终每个人都会有个人喜好。但是，我将尝试尽可能客观，并提出一些绩效方面的经验比较。
TL; DR —您可以在此处查看最终代码（每个集成都在不同的分支中）：github/jogilvyt/redux-context-recoil
应用程序
我构建了一个简单的待办应用程序，该应用程序呈现可以删除的项目列表以及添加新项目的表单。它使用setTimeout调用模拟API以获取结果，创建新项目并从列表中删除项目：
> Basic to-do application
为了获得性能的基准度量，我开始时根本没有全局状态管理。加载应用程序时总共有三个渲染：加载屏幕的初始渲染耗时5.3ms，项目加载后的重新渲染耗时7ms：
> Rendering after the results have been fetched
这是一个非常简单的应用程序，因此性能上的任何差异都不会很大，在更复杂的应用程序中，情况可能会有所不同。但这应该使我们对每个库的性能影响有一个非常高级的了解。
开始之前
对于新项目，确保您使用正确的工具来完成工作始终非常重要-因此现在是时候问问自己是否真的需要全局状态管理了。许多简单的应用程序都能很好地运行，并且更易于维护，而无需引入外部库甚至Context API的所有开销。作为UI工程师，我们会不顾一切地跳入每个闪亮的新工具，因此在声誉方面享有一定声誉。不要陷入陷阱-在进行整合之前，请确保您确实确实需要一个全局状态管理系统。
Redux可能是最完善的全局状态管理工具。它与框架无关，这意味着它已在整个前端世界中流行，并且有一段时间，当您需要超越本地状态时，它确实是唯一的选择。但是，随着最近添加的Context API和新的挑战者Recoil，Redux仍然可以在现代React应用程序中保持自己的地位吗？
性能
让我们从性能开始。初始加载时，只有两个渲染，而基线只有三个。但是，整体渲染时间会稍长一些-提取加载状态后需要6毫秒，而提取项目后则需要10.6毫秒来渲染列表：
> Redux: rendering after the results have been fetched
添加新项目后进行渲染需要2.9毫秒，而删除项目后要进行渲染需要2毫秒。因此，总的来说，除了加载应用程序时的初始开销外，性能还相当出色。
开发人员经验
对我而言，这一直是Redux的一大弊端。一直感觉需要很多样板来使其正常工作，并且在一个应用中使用多个reducer时很容易陷入重复。在这种情况下，我们有一个商店，一个reducer和三个动作，这对于这个基本的东西来说感觉像很多代码。
话虽如此，Redux擅长执行开发人员最佳实践，提供了易于遵循的模式，因此在构建功能时不必对实现进行太多决策。我还喜欢它如何将API请求抽象到操作中，从而将所有操作都集中在一个地方。当您知道去哪里更新API调用而不是深入研究组件以查找发出请求的组件时，这要容易得多。
用户体验
使用Redux管理加载和错误状态需要一些自定义实现。就我而言，我跟踪化简器中的全局isLoading变量，然后管理用于在每个组件中添加和删除项目的加载状态。这是相当标准的东西，并不难构建，但这是Recoil真正发挥作用的领域之一-稍后再介绍！
联系客服
