共计 4269 个字符，预计需要花费 11 分钟才能阅读完成。
在 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 前，在一次更新如下三个生命周期只会调用一次：
componentWillMountcomponentWillReceivePropscomponentWillUpdate
然而开启 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 怎么样？欢送留下你的探讨。
