React18，不远啦？

不念不忘少年蓝@ 2022-10-17 11:16 113阅读 0赞

在`React`前不久的一次PR \#21488中，核心成员**「Brian Vaughn」**对`React`内一些`API`、以及内部`flag`作出调整。

![dba721116e4f5089a623fd56fab9ffda.png][]

其中最引人注目的改动是：`React`入口增加`createRoot API`。

业界将这一变化解读为：`Concurrent Mode`（后文简称为`CM`）将在不久后稳定，并出现在正式版中。

![1a9dfe3c6d7bf081f217a63a8a0a82b5.png][]

`React17`是一个过渡版本，用以稳定`CM`。一旦`CM`稳定，那v18的进度会大大加快。

可以说从18年到21年，`React`团队的主要工作就是围绕`CM`展开的，那么：

*  `CM`是什么？
 *  `CM`能解决`React`什么问题？
 *  为什么经历快4年，跨越16、17两个版本，`CM`还不稳定？

本文将作出解答。

## CM是什么 ##

要了解`CM`（并发模式）是什么，首先需要知道`React`源码的运行流程。

`React`大体可以分为两个工作阶段：

*  `render`阶段

在`render`阶段会计算一次更新中变化的部分（通过diff算法），因组件的`render`函数在该阶段调用而得名。

`render`阶段**「可能」**是异步的（取决于触发更新的场景）。

*  `commit`阶段

在`commit`阶段会将`render`阶段计算的需要变化的部分渲染在视图中。对应`ReactDOM`来说会执行`appendChild`、`removeChild`等。

`commit`阶段一定是同步调用（这样用户不会看到渲染不完全的`UI`）

我们通过`ReactDOM.render`创建的应用属于`legacy`模式。

在该模式下一次`render`阶段对应一次`commit`阶段。

如果我们通过`ReactDOM.createRoot`（当前稳定版本中还没有此`API`）创建的应用属于开篇提到的`CM`（`concurrent`模式）

在`CM`下，更新有了优先级的概念，`render`阶段可能被高优先级的更新打断。

所以`render`阶段可能会重复多次（被打断后重新开始）。

可能多次`render`阶段对应一次`commit`阶段。

此外，还有个`blocking`模式用于方便开发者慢慢从`legacy`模式过渡到`CM`。

你可以从特性对比看到不同模式支持的特性：

![5c34ae9b4dfe2d06d4f3edb4f4c08256.png][] 不同模式支持的特性

## 为什么需要CM？ ##

知道了`CM`是什么，那么他有什么用？为什么`React`核心团队会耗时3年多（18年开始）来实现他？

这得从`React`的设计理念聊起。

我们可以从官网React哲学看到`React`的设计理念：

> 我们认为，`React`是用`JavaScript`构建**「快速响应」**的大型`Web`应用程序的首选方式。

其中**「快速响应」**是重点。

那么什么影响**「快速响应」**呢？`React`团队给出的答案：

> `CPU`的瓶颈和`IO`的瓶颈

### CPU的瓶颈 ###

考虑如下`demo`，我们渲染3000的列表项：

function App() {
      const len = 3000;
      return (
        <ul>
          {Array(len).fill(0).map((_, i) => <li>{i}</li>)}
        </ul>
      );
    }
    
    const rootEl = document.querySelector("#root");
    ReactDOM.render(<App/>, rootEl);

刚才说过，在`legacy`模式下`render`阶段不会被打断，则这3000个`li`的`render`都得在同一个浏览器宏任务中完成。

长时间的计算会阻塞线程，造成页面掉帧，这就是`CPU`的瓶颈。

解决的办法就是：启用`CM`，将`render`阶段变为**「可中断」**的，

当浏览器一帧剩余时间不多时将控制权交给浏览器。等下一帧的空余时间再继续组件`render`。

### IO的瓶颈 ###

除了长时间计算导致的卡顿，网络请求时的`loading`状态也会造成页面不可交互，这就是`IO`的瓶颈。

`IO`瓶颈是客观存在的。

作为前端，能做的只能是尽早请求需要的数据。

但是，通常情况下：**「代码可维护性」**与**「请求效率」**是相悖的。

什么意思呢，举个例子：

假设我们封装了请求数据的方法`useFetch`，通过返回值是否存在区分是否请求到数据。

function App() {
      const data = useFetch();
      
      return {data ? <User data={data}/> : null};
    }

为了提高**「代码可维护性」**，`useFetch`与要渲染的组件`User`存在于同一个组件`App`中。

然而，如果`User`组件内还需要进一步请求数据呢（如下`profile`数据）？

function User({data}) {
      const {id, name} = data?.id || {};
      const profile = useFetch(id);
      
      return (
        <div>
          <p>{name}</p>
          {profile ? <Profile data={profile} /> : null}
        </div>
      )
    }

本着**「代码可维护性」**原则，`useFetch`与要渲染的组件`Profile`存在于同一个组件`User`中。

但是，这样组织代码，`Profile`组件只能等`User` `render`后再`render`。

数据只能像瀑布的水一样，一层一层流下来。

这种低效的请求数据方式被称为`waterfall`。

![7d6641c06eb783b26b000e42beee1225.png][]

为了提高**「请求效率」**，我们可以将“请求`Profile`组件所需数据的操作”提到`App`组件内，合并在`useFetch`中：

function App() {
      const data = useFetch();
      
      return {data ? <User data={data}/> : null};
    }

但是这样就降低了**「代码可维护性」**（`Profile`组件离`profile`数据太远）。

`React`团队从`Relay`团队借鉴经验，借助`Suspense`特性，提出了Server Components。

就是为了在处理`IO`瓶颈时兼顾**「代码可维护性」**与**「请求效率」**。

这一特性的实现需要`CM`中**「更新有不同优先级」**。

## CM为什么花费这么久？ ##

接下来，我们从`源码`、`特性`、`生态`三个方面，自底向上看看`CM`的普及有多么不容易。

### 源码层面 ###

#### 优先级算法改造 ####

在v16.13之前，`React`已经实现了基本的`CM`功能。

我们之前聊过，`CM`有更新优先级的概念。之前是通过一个毫秒数`expirationTime`标记**「更新」**的过期时间。

*  通过对比不同更新的`expirationTime`判断优先级高低
 *  通过对比更新的`expirationTime`与当前时间判断更新是否过期（过期需要同步执行）

但是，`expirationTime`作为一个与时间相关的浮点数，无法表示**「一批优先级」**这个概念。

为了实现更上层的`Server Components`特性，需要有**「一批优先级」**这个概念。

于是，核心成员**「Andrew Clark」**开始了旷日持久的优先级算法改造，见：PR lanes

![c54353d93d0d2eac5c1fda8c22d5a8d5.png][]

### Offscreen支持 ###

在此同时，另一个成员**「Luna Ruan」**在开发一个新`API` —— `Offscreen`。

可以理解这是`React`版的`Keep-Alive`特性。

![a8f7c33b0852ed289d921e4656a961ad.png][]

### 订阅外部源 ###

未开启`CM`前，在一次更新如下三个生命周期只会调用一次：

*  `componentWillMount`
 *  `componentWillReceiveProps`
 *  `componentWillUpdate`

但是开启`CM`后，由于`render`阶段可能被打断、重复，所以他们可能被调用多次。

在订阅外部源（比如注册事件回调）时，可能更新不及时或者内存泄漏。

举个例子：`bindEvent`是一个基于**「发布订阅」**的外部依赖（比如一个原生`DOM`事件）：

class App {
      componentWillMount() {
        bindEvent('eventA', data => {
          thie.setState({data});
        });
      }
      componentWillUnmount() {
        bindEvent('eventA');
      }
      render() {
        return <Card data={this.state.data}/>;
      }
    }

在`componentWillMount`中绑定，在`componentWillUnmount`中解绑。

当接收到事件后，更新`data`。

当`render`阶段反复中断、暂停后，有可能出现：

> 事件最终绑定前（`bindEvent`执行前），事件源触发了事件

此时`App`组件还未注册该事件（`bindEvent`还未执行），那么`App`获取的`data`就是旧的。

为了解决这个潜在问题，核心成员**「Brian Vaughn」**开发了特性：create-subscription

![52b4bc70bd8a85d068ff51edbbc70deb.png][]

用来在`React`中规范外部源的订阅与更新。

简单说就是将外部源的注册与更新在`commit`阶段与组件的状态更新机制绑定上。

### 特性层面 ###

当**「源码层面」**的支持完备后，基于`CM`的新特性开发便提上日程。

这便是`Suspense`。

\[Umbrella\] Releasing Suspense \#13206，这个`PR`负责记录`Suspense`特性的进展。

> `Umbrella`标记代表这个`PR`会影响非常多库、组件、工具

可以看到，长长的时间线从18年一直到最近几天。

最初`Suspense`只是**「前端特性」**，当时`React SSR`只能向前端传递**「字符串」**数据（也就是俗称的`脱水`）

后来`React`实现了一套`SSR`时的组件**「流式」**传输协议，可以**「流式」**传输组件，而不仅仅是`HTML`字符串。

此时，`Suspense`被赋予更多职责。也拥有了更复杂的优先级，这也是刚才讲过的**「优先级算法改造」**的一大原因。

最终的成果，就是今年早些时候推出的`Server Components`概念。

## 生态层面 ##

当**「源码层面」**支持了、**「特性」**也开发完成了，是不是就能无缝接入呢？

还早。

作为一艘行驶了8年的巨轮，`React`每次升级到最终社区普及，中间都有巨量的工作要做。

为了帮助社区慢慢过渡到`CM`，`React`做了如下工作：

*  开发`ScrictMode`特性，并且是默认启用的，规范开发者写法
 *  将`componentWillXXX`标记为`unsafe`，提醒用户不要使用，未来会废弃
 *  提出了新生命周期（`getDerivedStateFromProps`、`getSnapshotBeforeUpdate`）替代如上将被废弃的生命周期
 *  开发了`legacy`模式与`CM`过渡的中间模式 —— `blocking`模式

而这，只是过渡过程中**「最简单」**的部分。

难的部分是：

> 社区当前积累的大量基于`legacy`模式的库如何迁移？

很多动画库、状态管理库（比如`mobX`）的迁移并不简单。

## 总结 ##

我们介绍了`CM`的来龙去脉以及他迁移的难点。

通过这篇文章，想必你也知道了开头那个为`React`增加`createRoot`（开启`CM`的方法）是多么不容易。

好在一切都是值得的，如果说以前`React`的壁垒在于：开源时间早、社区规模大。

那么从`CM`开始，`React` **「可能」**会是前端领域最复杂的视图框架。

届时，不会有任何一个`React-like`的框架能实现`React`同样的`feature`。

![48ed8c54f51d307611efd39548e17c05.png][]

但是也有人说，`CM`带来的这些功能就是鸡肋，我根本不需要。

你觉得`CM`怎么样？欢迎留下你的讨论。

[dba721116e4f5089a623fd56fab9ffda.png]: /images/20221014/157d18c765684eaa9352d87b3ae0ec2b.png
[1a9dfe3c6d7bf081f217a63a8a0a82b5.png]: /images/20221014/1c5abb0abb684a8c96ef08553938b584.png
[5c34ae9b4dfe2d06d4f3edb4f4c08256.png]: /images/20221014/7135e1adcf7d428bb83dbd5e13e707ff.png
[7d6641c06eb783b26b000e42beee1225.png]: /images/20221014/56b48975e823436bb225a5e321a76ce6.png
[c54353d93d0d2eac5c1fda8c22d5a8d5.png]: /images/20221014/541e4f6ec7e24eda8bc227d48eb343e8.png
[a8f7c33b0852ed289d921e4656a961ad.png]: /images/20221014/7f478fe8fb5a42e9a3094cd3e2038642.png
[52b4bc70bd8a85d068ff51edbbc70deb.png]: /images/20221014/7b5dea7149a741e0a695aacced4ba2a5.png
[48ed8c54f51d307611efd39548e17c05.png]: /images/20221014/d0f42b5307e9461b963d37be16316c7d.png