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

其中最引人注目的改变是：React入口减少createRoot API。

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

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。

你能够从个性比照看到不同模式反对的个性：

为什么须要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。

为了进步申请效率，咱们能够将“申请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

Offscreen反对

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

能够了解这是React版的Keep-Alive个性。

订阅内部源

未开启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

用来在React中标准内部源的订阅与更新。

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

个性层面

当源码层面的反对齐备后，基于CM的新个性开发便提上日程。

这便是Suspense。

[[Umbrella] Releasing Suspense #13206](https://github.com/facebook/r...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。

然而也有人说，CM带来的这些性能就是鸡肋，我基本不须要。

你感觉CM怎么样？欢送留下你的探讨。