首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

为什么我不会怀念 React?

工程师 Jack Franklin 过去每天都使用 React,直到后来他加入谷歌从事 Chrome DevTools 工作,工作重点变成了引入 Web Components,他发现自己离开 React 之后好像也没有想象中的那样怀念 React。本文是他关于 React 和 Web Components 的一些实践与思考。

两年多前,我从伦敦一家初创公司离职,在那里,我负责开发基于 React 的大型电子商务前端。离职后,我加入了谷歌,从事 Chrome DevTools 的工作。我最初的工作重点是引入 Web Components,这是一个新的测试基本构建块,用于开发新的 DevTools 特性和用户界面。由于最近 Recorder 面板和其他面板的发布,现在,DevTools 中的很大一部分几乎都是 Web Components。

我曾经预计,当我离开以 React 为中心的角色后,会发觉转型很困难,并会怀念 React 所提供的东西。结果,我发现转型要比预期容易得多,并且我真的很享受更接近平台原语的工作,对我所编写的软件保持了更多的控制,在本文中,我想分享一下这个原因。

首先,以防引发歧义和争论,我想先清楚地阐明本文不是什么:

  • 本文并非呼吁每个人都立刻抛弃 React,转而使用 Web Components。
  • 本文并非宣告 React “死亡”的博文,也并非所有项目的错误选择。
  • 本文并非宣称 Web Components 是所有项目的最佳解决方案。
  • 本文亦并非宣称所有的 Web 框架都是没用的或者很糟糕的选项。
  • 本文并非博文暗示,因为这种方法适用于我和我在谷歌的团队,因此对于你来说也是一样。所有的项目都不尽相同,而且几乎可以肯定的是,Chrome DevTools 对于你的项目有着不同的需求和约束。那也无所谓。本文应该被解读为一个人从每天使用 React 到不去触碰它的思考,以及这样做的经验。我之所以写下这篇博文,是因为我惊喜地发现,我是如此享受与 Web 平台更紧密的合作。

虽然我会用 “React” 作为我的比较,但你可以合理地将其替换为任何大型现代框架。

使用平台

近年来,“使用平台”已经成为一个有点被过度使用和滥用的短语,但是它的核心原理却让我产生了共鸣:我们能不能利用浏览器和 JavaScript 中的 API,在无需第三方依赖项的情况下,为我们的用户开发特性?

注意:这里的答案并不总是“是”!我还是想把更多的特性添加到浏览器中。但是,相对于十年前,这个原生特性的范围有了很大的拓展。一个典型的例子就是构建表单:这曾经是一个使用 React 的合理理由,因为在这里,浏览器只提供了原始的特性。快进几年后,在最近的一个项目里,我可以用 100% 的原生特性来构建具有坚实用户体验的表单:

  • 我使用 HTML 验证属性来强制执行必填字段(还可以使用基于模式的验证做得更多)。
  • 我使用 FormData API 从表单中读取数值,而不是在状态中跟踪它们的数值(我不需要这样做,因为验证是由浏览器完成的)。
  • 如果我愿意,我甚至可以使用约束验证 API 来定制错误信息——直到几天前我才知道这个 API 的存在!这是不是比使用 npm 的一个库来为我打包这一切更费事?有可能!但是我可以通过多写一些代码来达到相同的效果,而不会因为额外的依赖项而影响到我的应用。

保持控制

当我刚开始使用 React 时,我最担心的就是如何适应自定义元素,但是我真的很喜欢用它们工作。

自定义元素可能会让你更容易写出更多的代码,但是,如果你以前用过任何一个流行的组件库,那么你就可以创建出一些令人惊讶的、熟悉的东西,但是有一个关键的区别:你不会放弃控制。

React 不允许你自行决定如何以及何时将你的组件渲染到页面上。你使用它的结构来编写代码,它决定何时渲染。10 次中有 9 次——甚至 100 次中有 99 次或更多——这完全符合你的预期。但是 Web 平台并非十全十美,我猜想大多数 React 开发者都会遇到过这样的情况:你很渴望能够调整自己的组件的渲染方式。

如何放弃对渲染过程的控制,将会导致混乱,正如 Gary Bernhardt 所发的这条推文一样:

为什么这段代码:console.log(mark ${Math.random()})alert(mark ${Math.random()})打印一条日志,但是显示两个警报?因为 React.StrictMode 隐藏了一条日志来“帮助”我为并发模式做准备。React 很好,但对于 99.9% 的应用来说,并发模式感觉就是个错误。这种行为现在已经在 React v18 中有所改变了,但是 React 不得不抑制额外的 console.log调用,这是它渲染我的应用的结果,这一事实让我感到惊讶;正是这种在我自己的应用中缺乏控制的情况,已经让我感到非常警惕。

在软件开发中,这被称为控制反转(Inversion of Control)。当你使用像 React 这样的框架时,你的代码将不再直接控制组件(或函数)何时被调用。你的组件并不直接告诉 React 何时重新渲染它们,而是由 React 决定。你的组件已经把控制让给了 React。

我们的自定义元素解决方案不会有这种控制的倒置;我们通过明确地调用一个函数(在 lit-html 的例子中,它是一个名为 html带标签模板源文本)来控制每一次渲染。

没有使用 React 这种框架的不利之处在于,你必须考虑重新创建那些原本内置的部分,比如,确保我们批量渲染的基本调度器,或者使这些组件更容易测试的测试助手库。在这种情况下,你必须仔细考虑你的选择:如果我们避免使用 React,但最终重新实现了它提供的大部分内容,那么我们使用框架会可能会更好。在我们的案例中,我们依然认为这样的决策是合理的,因为我们不必重新构建一个具有 React 的所有复杂性的调度器:我们可以构建一个小型的、独立的实现,只实现我们所需要的东西。

在构建了我们的基本调度器之后,我们可以清楚地知道每个组件的渲染原因和时间,并且当我们需要偏离标准路径时,我们就能够实现。这种感觉很有价值:我所开发的每个软件项目中,都有至少一种组件需要做一些不同的事情来处理奇怪的边缘情况。

选择可以轻松替换的依赖项

自定义元素缺乏的一个领域是某种形式的 HTML 模板解决方案,它提供了高效的 HTML 重渲染。我肯定会建议使用一个库来解决这个问题,而我们选择了 lit-html。lit-html 的魅力在于,它只是我们解决方案中的一小部分。我们本可以选择 Lit,一个基于自定义元素形成的功能更全面的组件库,但是这样做,会导致我们增加依赖项,同时也会失去一定的控制(重申我在这篇博文前面提出的观点:这不是对 Lit 的批评,对很多人来说 Lit 是正确的选择!)。

Lit-html 可以确保我们的 HTML 被有效地渲染,并且提供了一套很好的指令,让我们可以轻松地完成常见的任务,如有条件地应用类。虽然没有 JSX 那么完美,但是也非常的接近。

最重要的是什么?它是一个非常小的依赖项(3.3kB gzipped),更重要的是,如果我们需要的话,可以很容易地被替换。这听起来很消极,甚至很悲观,但当我们采用一个新的依赖项时,我们要问的一个主要问题是:“如果它消失了会怎样呢”?

假定 React 已经消失(这并不是说我认为它会消失)。我们处理这个问题的代价是什么?我们有几个选择:

  • 维护 React 的复刻(fork),无论我们目前使用的是哪个版本。
  • 将我们所有的组件从 React 迁移到其他地方。这两个选项对我都没有吸引力;维护一个库意味着我们要么什么都不做,要么错过改进和/或安全修复;而迁移我们所有的组件,那就是一项浩大的工程了。我确信,一旦出现这样的情况,React 的复刻将会如雨后春笋般涌现出来,但是不管怎么说,它都需要很多的努力,经过很多的波折,才能使事情变得更健壮。迁移我们所有的组件,花费会非常大,而且对最终用户来说,也没有什么实际的好处,这对于企业和领导层而言是非常困难的。我们还必须学习一种新的框架(即使它与 React 相似),并且在这个框架中增加我们的专业知识。

这与自定义元素和 Lit-html 形成了鲜明对比。我们可以有很好的信心,自定义元素不会突然消失;它被嵌入到浏览器中,并且向后兼容是 Web 平台的一个核心原则。

如果你在想自定义元素 v0 被移除而改用 v1,请记住 v0 是 Chrome 浏览器的特定实验性规范,而 v1 是一个跨平台的标准化规范。v0 的目的是收集开发者的反馈,以便为未来的标准化规范提供参考。要是 lit-html 从互联网上消失了呢?我们有同样的两个选择:维护一个复刻,或者取代它。维护复刻并不理想,原因与维护 React 复刻不理想一样,但有一点不同:lit-html 的范围要小得多,而且一般来说它是一个小得多的库。这将减少我们的工作量,使我们能够在需要时进行修复或改进。

替换 lit-html 将是一项工作,但比替换 React 要少得多:它在我们的代码库中纯粹是用来让我们的组件(重新)渲染 HTML。替换 lit-html 仍然意味着我们可以保留我们的业务逻辑,最终保持它们为最终用户提供的价值。Lit-Html 是我们系统中的一块小的“乐高砖”,React(或 Angular,或类似)是整个“盒子”。

第三方依赖项的成本

第三方依赖,无论大小,都会有一系列的成本,你的用户和/或开发人员将为此支付。每个人对这一成本是否值得的看法会有所不同,这取决于你的应用程序和技术栈,但当我考虑添加新的依赖项时,会出现以下一组成本:

  1. 包大小:这个依赖对我们必须在浏览器中交付和执行的最终 JavaScript 增加多少权重?对于这个依赖项所提供的东西来说,这个包的大小是否合适和值得?
  2. 突破性变化和升级:如果软件包有一个大的改动,需要工作来升级到最新版本,会发生什么?我们是继续使用旧版本(如果它没有得到更新或安全修复,那就不太理想),还是投入工作来升级?升级的工作是否可以很快得到优先考虑,或者是我们可能永远无法完成的工作类型?
  3. 未维护的代码或问题的风险:谁能说第三方的依赖项可能有特定的漏洞或问题而导致问题?(这并不是批评所有那些孜孜不倦地维护开源软件的人——但这些事情常会发生)。Jeremy Keith 在他最近关于信任的文章中指出:

你添加到项目中的每一个依赖项都是多一个潜在的单点故障。你自己的代码也是如此(把“依赖项”换成“文件”),但关键是你有完全的控制,你可能更熟悉它的工作原理,因为它是在内部编写的,而且你不需要对其他人负责来修复上游的问题。这并不是说你应该在每个项目上都重新创建一个世界;在自己构建和添加依赖项之间总是有一个很好的平衡,而且没有任何规则可以决定每次的正确结果。

总结

这篇文章并不是说你不应该接触依赖项。在回应 Jeremey Keith 关于信任和第三方依赖项的帖子时,Charles Harries 提出,跨浏览器兼容性在历史上是依赖项的驱动力

浏览器兼容性是库(尤其是 Jeremy 提到的大库),如 React 和 Bootstrap--向开发者作出的基本承诺之一。我没有足够的时间在 caniuse.com 上浏览 Array.prototype.includes 或 MutationObserver 的页面。Lodash 在其主页的底部就承诺了跨平台兼容性。我完全同意 Charles 的观点,这也是为一个浏览器开发工具的工作具有优势的一个领域,因为我们了解用户对浏览器的偏好。

我希望,随着浏览器所支持的基线特性集越来越统一,尤其是 IE 浏览器的消亡,我们的行业可以随着时间的推移,在缺省的状态下,能够实现浏览器的广泛内置特性,在绝对必要的情况下进行多重填充,并把框架作为默认的起点。

作者介绍:

Jack Franklin,谷歌工程师,负责构建 Chrome DevTools。

原文链接:

https://www.jackfranklin.co.uk/blog/working-with-react-and-the-web-platform/

  • 发表于:
  • 本文为 InfoQ 中文站特供稿件
  • 首发地址https://www.infoq.cn/article/iq8WxF2Ia9sMKZ6kcSSl
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券