有学有练才叫学习:学而不思则罔,思而不学则殆:学而不习,纸上谈兵,习而不进,画地为牢!

react recoil Redux,Context或Recoil:哪一种适合您的应用

前端框架 炮渣日记 2周前 (11-14) 24次浏览 已收录 0个评论 扫描二维码

全局状态管理中三个竞争者的比较

react recoil Redux,Context或Recoil:哪一种适合您的应用

> Photo by Joshua Aragon on Unsplash

随着全局状态管理工作的日新月异,可能很难知道该选择哪个选项。Redux在很长一段时间以来一直是被选择的库,但是由于提供了状态管理的Context API已嵌入到React本身,许多人已经宣布Redux已死。现在,随着Facebook支持的早期项目Recoil的发布,我们有了一个特定于React的库,可以轻松地与React的最新功能集成。

但是哪一个最适合您的项目?在本文中,我将与每个库集成一个简单的应用程序,并提供一些比较和观察。这些只是我的意见-我绝对不会将我的发现作为事实提出,最终每个人都会有个人喜好。但是,我将尝试尽可能客观,并提出一些绩效方面的经验比较。

TL; DR —您可以在此处查看最终代码(每个集成都在不同的分支中):
https://github.com/jogilvyt/redux-context-recoil

应用程序

我构建了一个简单的待办应用程序,该应用程序呈现可以删除的项目列表以及添加新项目的表单。它使用setTimeout调用模拟API以获取结果,创建新项目并从列表中删除项目:

react recoil Redux,Context或Recoil:哪一种适合您的应用

> Basic to-do application

为了获得性能的基准度量,我开始时根本没有全局状态管理。加载应用程序时总共有三个渲染:加载屏幕的初始渲染耗时5.3ms,项目加载后的重新渲染耗时7ms:

react recoil Redux,Context或Recoil:哪一种适合您的应用

> Rendering after the results have been fetched

这是一个非常简单的应用程序,因此性能上的任何差异都不会很大,在更复杂的应用程序中,情况可能会有所不同。但这应该使我们对每个库的性能影响有一个非常高级的了解。

开始之前

对于新项目,确保您使用正确的工具来完成工作始终非常重要-因此现在是时候问问自己是否真的需要全局状态管理了。许多简单的应用程序都能很好地运行,并且更易于维护,而无需引入外部库甚至Context API的所有开销。作为UI工程师,我们会不顾一切地跳入每个闪亮的新工具,因此在声誉方面享有一定声誉。不要陷入陷阱-在进行整合之前,请确保您确实确实需要一个全局状态管理系统。

Redux

Redux可能是最完善的全局状态管理工具。它与框架无关,这意味着它已在整个前端世界中流行,并且有一段时间,当您需要超越本地状态时,它确实是唯一的选择。但是,随着最近添加的Context API和新的挑战者Recoil,Redux仍然可以在现代React应用程序中保持自己的地位吗?

性能

让我们从性能开始。初始加载时,只有两个渲染,而基线只有三个。但是,整体渲染时间会稍长一些-提取加载状态后需要6毫秒,而提取项目后则需要10.6毫秒来渲染列表:

react recoil Redux,Context或Recoil:哪一种适合您的应用

> Redux: rendering after the results have been fetched

添加新项目后进行渲染需要2.9毫秒,而删除项目后要进行渲染需要2毫秒。因此,总的来说,除了加载应用程序时的初始开销外,性能还相当出色。

开发人员经验

对我而言,这一直是Redux的一大弊端。一直感觉需要很多样板来使其正常工作,并且在一个应用中使用多个reducer时很容易陷入重复。在这种情况下,我们有一个商店,一个reducer和三个动作,这对于这个基本的东西来说感觉像很多代码。

话虽如此,Redux擅长执行开发人员最佳实践,提供了易于遵循的模式,因此在构建功能时不必对实现进行太多决策。我还喜欢它如何将API请求抽象到操作中,从而将所有操作都集中在一个地方。当您知道去哪里更新API调用而不是深入研究组件以查找发出请求的组件时,这要容易得多。

用户体验

使用Redux管理加载和错误状态需要一些自定义实现。就我而言,我跟踪化简器中的全局isLoading变量,然后管理用于在每个组件中添加和删除项目的加载状态。这是相当标准的东西,并不难构建,但这是Recoil真正发挥作用的领域之一-稍后再介绍!

Context API

新的Context API在版本16.3中引入了React,旨在提供一种在组件之间共享状态的方式,而不必将其“提升”到公共父级。现在,它已被广泛用作存储全局状态的方法,尤其是用于存储更多静态数据(例如用户信息或主题首选项)时。让我们看看它与Redux的比较。

性能

据说Context在性能方面并不是很好,因为当Provider中的状态更新时,消耗Context的每个组件都将重新呈现,即使与该组件相关的状态没有改变。

对于我们的应用程序,加载时有三个渲染:初始加载状态花费5.9毫秒,获取数据后有2.9毫秒的渲染,最后花费7.6毫秒来渲染待办事项。

react recoil Redux,Context或Recoil:哪一种适合您的应用

> Context: rendering after the results have been fetched

这看起来与Redux的渲染时间大致相似。但是,添加或删除项目时,时间会更长:添加项目后要重新渲染的时间为4.9ms,删除项目后为4.5ms(相比之下,Redux分别为2.9ms和2ms)。

开发人员经验

对我来说,这就是Context API真正发挥作用的地方。它内置于React中,因此如果您发现自己需要全局状态管理而无需任何重大架构更改或添加整个新库,则可以将其逐步引入项目中。我也喜欢与钩子集成多么容易。在此应用程序中,我创建了一个useToDos挂钩,该挂钩将状态从上下文中拉出,然后可以在使用该状态的任何组件中调用它:

const { toDos } = useToDos();

您甚至可以将其与React的useReducer挂钩集成,以管理复杂状态。我发现这是管理具有很多子组件和复杂功能的组件的共享状态的一种非常有用的方法。

用户体验

处理加载和错误状态的方式与Redux非常相似:我们需要编写一些自定义代码来处理每个加载状态,并且所有错误处理都需要围绕API调用本身进行。这是在Redux操作中使用API请求的地方。使用Context,我们必须在调用API的任何地方添加错误处理,这意味着一些重复或重构。

Recoil

Recoil是个新手,自去年发布以来引起了轰动。它得到了Facebook的支持,Facebook的团队还维护着React,并且与许多最新的React功能(例如并发模式)很好地集成在一起。它仍处于开发的早期阶段,不建议在生产应用中使用。但是,以目前的新生形式,它与我们拥有的其他选择相比如何?

性能

Recoil的初始载荷是三个选项中最慢的。总共有五次渲染,其中第一渲染耗时11.2毫秒,其次是两次稍快的重新渲染(1.1毫秒和0.2毫秒),然后在加载待办事项后重新渲染了5毫秒,最后是1.9毫秒来渲染。屏幕上的项目。

react recoil Redux,Context或Recoil:哪一种适合您的应用

> Recoil: It took 11.2ms to render just the loading screen

但是,添加和删除项目非常简单:添加项目后重新渲染2.4毫秒,删除项目后重新渲染3.7毫秒。这似乎与Redux大致相符。

这里还值得指出的是,Recoil软件包的大小为45.1K(根据我的Import Cost VS Code插件),而Redux(合并redux和react-redux软件包)则为1.17K,而Context则一无所有作为React的一部分。随着图书馆工作的进行,这种情况可能会发生变化,但要记住这一点。

开发人员经验

尽管这是我第一次使用Recoil,但在了解原子和选择器之后,我发现它易于使用。我喜欢如何在选择器中发出异步请求以初始化API请求的状态:

在组件中使用状态也非常容易。它的工作方式与useState类似:

const [toDos, setToDos] = useRecoilState(toDosAtom);

我发现一个令人困惑的地方是在添加或删除项目后更新状态。使用异步选择器,我认为能够具有类似的setter函数(可用于基于API请求的响应来更新状态)会很酷。这可能是稍后添加的内容;现在,我只是在组件中进行了API调用,并将状态设置为响应:

用户体验

对我而言,Recoil真正发挥了作用。它与React的并发模式集成在一起,使您可以使用Suspense处理错误的加载状态,并使用ErrorBoundary处理错误。这意味着您可以以更具声明性的方式构建应用程序。我能够将我的应用程序包装到具有后备功能的Suspense组件中,并且自然地呈现了加载屏幕,直到API请求完成并加载了待办事项。

这样做的一个副作用是,它确实会迫使您做出一些架构决策。将Recoil集成到成熟的应用程序中可能很困难,并且如果您偏爱以某种方式执行操作,则可能会难以在库的限制内工作。但是,它肯定比Redux更具React-y。

结论

Redux已经确立了其作为全局状态管理领导者的地位,这肯定不会很快发生。但是,Context和Recoil正在成为严肃的竞争者,并且绝对感觉它们在React中的表现会更好。

我倾向于将Context用于不会对性能造成轻微影响的小型应用程序。对于较大的项目,Recoil仍然感觉有一些初期问题,我绝对不建议在生产应用程序中使用它。但是给定时间,它似乎确实可以提供更好的开发人员体验,并最终提供更好的用户体验。令人高兴的是,看到Recoil与React的新功能很好地集成在一起,当我们开始在应用程序中使用这些功能时,我认为Recoil将成为全局状态管理的自然选择。

感谢您的阅读,如果不确定哪个全局状态管理库适合您,希望对您有所帮助。

喜欢 (0)
炮渣日记
关于作者:
发表我的评论
取消评论
表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址