近日 React 18 已经正式发布了,带来了许多令人兴奋的新特性。在这个版本中,React 通过其改进的渲染系统带来了并发能力,并在此基础上构建了转换或自动批处理等性能增强特性。
本文将介绍这些特性的机制,以及它们对 React 开发人员有哪些帮助。
正式发布之路
在深入了解所有特性之前,我们先来回顾一下 React 18 发布背后的整个过程,因为与之前的版本相比这一次的发布经历非常独特。React 17 并没有带来很多新特性。然而它改进了很多基础组件,支持新 React 特性的无缝渐进采用,从而为未来的更新奠定了基础。这些更改的效果现在就体现在了 React 18 中。
React 发布过程中最显著的变化是与官方 alpha 版本一起,宣布新成立的 React 工作组(WG)。该小组的目标是收集来自社区的反馈,并帮助生态系统为即将到来的变化做好准备。此外,它是关于 React 内部工作的重要知识来源。
感谢 React 17 的改进和工作组的投入,React 18 最终成为了一个具有丰富特性的版本,却只有少量、重大更改。
重大更改
由于新的并发特性是渐进适配并按需启用的,React 18 中的重大更改仅限于几个简单的 API 更改,以及对 React 中多个行为的稳定性和一致性的一些改进。
客户端渲染 API
请注意,这个新的 API 现在已从 react-dom/client 模块导出。
卸载和水合 API 也发生了变化。
由于使用 Suspense 时会出现不正确 timing 的问题,渲染回调已经一去不复返了。替代选择(虽然不是一对一的替换)是顶部组件内部的一个效果:
自动批处理
createRoot() API 还是 React 18 中另一个改进的入口——自动批处理。在 React 的早期版本中,状态更新在 React 事件侦听器中完成时已经批量处理了,以优化性能并避免重渲染。从 React 18 开始,状态更新也将被安排到其他地方——比如在 Promise、setTimeout 回调和原生事件处理程序中。
这个更改虽然一般来说符合人们期望,也挺有用,但可能是破坏性的。如果你的代码依赖于在分开的状态更新之间重渲染的组件,那么你必须使其适应新的批处理机制,或使用 flushSync()函数来强制立即刷新更改。
严格模式更新
React 18 带来了大把新特性,此外还有很多新特性正在路上。为了让你的代码为此做好准备,StrictMode 变得更加严格了。最重要的是,StrictMode 将测试组件对可重用状态的弹性,模拟一系列的挂载和卸载行为。它旨在让你的代码为即将推出的特性(可能以<Offscreen>组件的形式)做好准备,这将在组件的挂载周期中保留这个状态。
虽然它肯定会在未来提供更好的性能,但就目前而言,启用 StrictMode 时必须要考虑这个事情。
其他更改
除了以上提到的更改之外,根据你的 React 代码库,你可能还会发现其他一些更改。
值得一提的是,React 18 将不再支持 Internet Explorer,因为 React 18 现在依赖很多现代浏览器特性,如 Promise 或 Object.assign。鉴于微软将在今年 6 月 15 日停止对该浏览器的支持,React 和其他 JS 库也将停止对它的支持是很自然的。那些仍然需要支持 IE 的人们将不得不继续使用 React 17。
其余的更改与一些 React 行为的稳定性和一致性有关,不太可能影响你的代码库。不管怎样,你可以在此处找到完整更改列表。
并发的 React
并发渲染器是 React 渲染系统的一项幕后特性。它允许并发渲染,即同时在后台准备多个版本的 UI。这意味着更好的性能和更平滑的状态转换。
虽然并发似乎只是一个实现细节,但其实它是大多数新特性的动力源泉。事实上,只有当你使用其中一种特性(如 transition、Suspense 或流式 SSR)时,才会启用并发渲染。这就是为什么了解并发渲染的工作机制是非常重要的。
Transition
Transition是由并发渲染提供支持的新特性之一。它旨在与现有状态管理 API 一起使用,以区分紧急和非紧急状态更新。通过这种方式,React 知道哪些更新需要优先考虑,哪些更新需要在后台通过并发渲染准备。
要知道何时使用 transition,你必须更好地了解用户是如何与你的应交互的。例如,在字段中键入或单击按钮是用户期望立即获得响应的操作——响应可能是出现在文本字段中的一个值,或是要打开的某个菜单。但对于搜索、加载或处理数据(例如搜索栏、图表、过滤表等)这些事情,用户也会期望它们需要一些时间来完成。后者就是你使用 transition 的场景了。
你可以使用 useTransition()钩子来创建一个 transition。这个钩子返回一个函数来启动一个 transition,还有一个挂起的指示器来通知你 transition 的进度。
你在 startTransition()回调中提交的任何状态更新都将被标记为 transition,从而使其他更新具有优先权。如果你不能使用这个钩子,还有一个单独的 startTransition()函数可用——虽然它不会通知你转换的进度。
Suspense 更新
与 React Suspense 结合使用时,transition 的效果是最好的。由于一些改进,Suspense 现在可以很好地与并发渲染集成、在服务器上工作,并且可能很快支持 lazy()加载组件之外的用例。与 transition 一起使用时,Suspense 将避免隐藏现有内容。考虑以下示例:
在状态改变时,lazy()加载的组件将触发 Suspense,导致 fallback 元素的渲染。如果你将状态更改标记为一个 transition,React 将知道它应该在后台准备新视图,同时仍保持当前视图可见。
现在,即使在处理 transition 时视图不会改变,你仍然可以使用过渡指示器来向用户提供反馈,例如设置容器不透明度。将上述改进与未来 Suspense 的新能力(与 lazy()加载的组件之外的异步任务一起使用)相结合,意味着 Suspense 将成为 React 最强大的特性之一。
服务端渲染改进
除了 Suspense 支持之外,React 的 SSR 方面还有很多其他变化。将 Suspense 与 SSR 流式传输和懒惰水合(lazy hydration)相结合,意味着你的服务端渲染应用将尽快水合并可用。不仅如此,零打包体积的服务端组件即将到来。它们目前处于试验阶段,但可能会在以后的次要版本中进入稳定状态。使用它们时,你将能减少提供给客户端的 JS 代码,甚至进一步优化 React 应用程序的性能和加载时间。
渐进采用
由于前文提到的 React 17 的多个更改,即使你的代码库很大,你也应该能够轻松地逐步采用 React 18。你不仅可以在应用程序的选定部分中使用新版本,还可以从 render()迁移到 createRoot(),来一步步选择加入新的特性和行为。最重要的是,即使使用的是 createRoot(),你仍然可以逐步采用并发渲染,因为它只有在你使用它的特性时才会启用。总体而言,迁移过程应该很顺利,甚至会是一桩乐事。
React 的未来
React 18 带来了许多新特性,你也可以看到一些即将出现的新事物。服务器组件、用于数据获取的 Suspense,和<Offscreen>组件渲染都是接下来的新特性的一部分。
React 正在与它的整个生态系统一起发展,我迫不及待地想看看接下来会发生什么!
原文链接:https://blog.openreplay.com/react-18-features-breakdown
评论