React: concurrent model 发生了什么？

最新推荐文章于 2024-09-12 07:30:00 发布

走在前端大牛的路上

最新推荐文章于 2024-09-12 07:30:00 发布

阅读量267

点赞数

分类专栏：学习笔记文章标签： react reactjs

原文链接：https://github.com/reactwg/react-18/discussions/64

版权

学习笔记专栏收录该内容

15 篇文章 1 订阅

订阅专栏

React 18引入了并发语义、协作多任务等新功能，旨在提高性能和用户体验。开发人员可通过startTransition和Suspense等API选择加入并发渲染，逐步升级应用。原有的阻塞模式和并发模式的概念被淡化，重点放在并发功能的增量采用上。

摘要由CSDN通过智能技术生成

概述

React 18 将添加新功能，例如startTransition、useDeferredValue、并发Suspense语义SuspenseList、等。为了支持这些功能，React 添加了协作多任务、基于优先级的渲染、调度和中断等概念。

这些功能通过更智能地决定何时渲染（或停止渲染）应用程序中的子树来解锁新的性能和用户体验。这些功能的代价是需要以一种能够适应这些新概念的方式编写代码。

为了帮助用户了解他们的代码是否兼容，React 添加了一组开发警告和行为，称为StrictMode，它警告用户不安全行为，并清除开发中的任何错误，如果您在生产中使用并发功能，这将是一个问题。我们在 React 16.3 中添加了 StrictMode，以允许社区为新功能做好准备。

这篇文章面向那些密切关注实验分支并想知道并发“模式”发生了什么的用户。它将概述推出这些功能的计划如何随着时间的推移而变化，并解释我们所说的没有并发“模式”，只有并发功能的意思。

什么是并发“模式”

将这些功能添加到 React 的最初想法是，这将成为所有应用程序的默认行为。这意味着，当您升级时，您将为整个应用程序打开并发“模式”。这将使您的所有应用程序选择并发渲染。为了确保这是安全的，我们还计划默认开启 StrictMode。这种策略的想法是，用户只需升级即可在整个应用程序中获得并发渲染的性能优势。

但是，在听取了社区关于更改影响的反馈以及对逐步升级的担忧后，很明显该策略需要一个渐进的故事。React 17 是第一步。

通过允许应用程序在 React 17 中的同一个应用程序中使用多个 React 版本，用户可以逐步将整个根目录转换为 React 18，并在 React 17 上保留旧的根目录，呈现与以前相同的版本。这种策略的缺陷在于，根目录可能很大，并且会在您的应用程序中散布成百上千个文件。因此，在 root 中，用户需要一种方法来逐步采用 React 18。

增量尝试 #1：阻塞模式

逐步采用并发模式的第一个策略是拥有三种模式：

Legacy Mode：React 17 中使用的当前模式。
- 默认情况下禁用 StrictMode
- 默认同步
- 遗留悬念语义
阻塞模式：传统和并发之间的混合模式。
- 默认启用 StrictMode
- 默认同步
- 一些新功能
并发模式：React 18 中使用的新模式。
- 默认启用 StrictMode
- 默认并发
- 所有新功能

使用此策略，用户将首先将其现有的传统模式根转换为阻塞模式，然后从阻塞模式转换为并发模式。

阻塞模式将启用所有 StrictMode 警告和开发模式行为，而无需更改更新或暂停语义。这将允许用户在他们的代码继续在生产中工作时查看他们根目录中的所有问题并修复它们。一旦所有问题得到解决，用户就可以毫无问题地打开并发模式。

阻塞模式的问题

我们发现这种策略存在一些问题。

通过在阻塞模式下启用所有 StrictMode 警告，用户仍然会被警告淹没，而没有一个好的增量策略来修复它们。尽管该应用程序仍然可以“工作”，但用户没有一个很好的方法来消除噪音并开始解决开发中强制的所有问题。这种增量转换根的策略在实践中证明仍然是全有或全无。
我们意识到应用程序通过使用并发功能可以获得并发渲染的最大好处。默认情况下启用并发渲染仍然是有益的（也许我们将来有一天会这样做），但大部分价值在于通过像 startTransition 或 Suspense 这样的 API 进行并发渲染。这意味着，我们不需要更改默认语义。相反，用户可以通过使用并发功能来选择加入并发渲染，这允许他们在获得并发功能的好处的同时，逐步测试和升级应用程序到新的语义。
通过上述更改，阻塞模式和并发模式之间的唯一区别是默认情况下阻塞模式将启用所有警告。但是如果默认没有并发渲染，那么我们就不需要默认开启严格模式了。此外，在进行了更多研究之后，我们现在认为我们对并发警告过于谨慎，在大多数代码可以工作时过于急切地表达了担忧，尤其是对于上述更改。

由于这些原因，我们已经意识到对整个应用程序中的每个理论错误发出警告，如果不使用并发功能可能出现错误，我们将不必要地阻止迁移。这导致了对迁移策略的重新思考。