大家好，我卡颂。
React18已经进入RC(release candidate)阶段，距离正式版只有一步之遥了。
v18新增了很多特性，今天，我们不聊新特性，而是来讲讲v18相比老版更优秀的一个细节：
v18中，组件render的次数可能更少。
在如下组件中：
复制
function App() { const [num, update] = useState(0);
// ...省略
1.
2.
3.
App组件render后会执行useState，返回num的最新值。
也就是说，组件必须render，才能知道最新的状态。为什么会这样呢?
考虑如下触发更新的代码：
复制
const [num, update] = useState(0);const onClick = () => { update(100); update(num + 1); update(num => num * 3);
}
1.
2.
3.
4.
5.
6.
onClick执行后触发更新，更新导致App组件render，进而useState执行。
在useState内部，会遵循如下流程计算num：
update(100)将num变为100。
update(num + 1)将num变为100 + 1 = 101。
update(num => num * 3)将num变为101 * 3 = 303。
即，App组件render时，num为303。
所以，状态的计算需要先收集触发的更新，再在useState中统一计算。
对于上述例子，将更新分别命名为u0～u2，则状态的计算公式为：
复制
baseState -> u0 -> u1 -> u2 = newState
1.
Concurrent(并发)为React带来了「优先级」的概念，反映到「状态计算」上，根据触发更新的场景，更新拥有不同优先级(比如onClick回调中触发的更新优先级高于useEffect回调中触发的更新)。
表现在计算状态中的区别就是，如果某个更新优先级低，则会被跳过。
假设上述例子中u1优先级低，那么App组件render时，计算num状态的公式为：
复制
// 其中u1因为优先级低，被跳过baseState -> u0 -> u2 = newState
1.
2.
即：
update(100)将num变为100。
update(num => num * 3)将num变为100 * 3 = 300。
显然这个结果是不对的。
所以，并发情况下React计算状态的逻辑会更复杂。具体来讲，可能包含多轮计算。
当计算状态时，如果某次更新被跳过，则下次计算时会从被跳过的更新继续往后计算。
比如上例中，u1被跳过。当u1被跳过时，num为100。此时的状态100，以及u1和「他后面的所有更新」都会保存下来，参与下次计算。
在例子中即为u1、u2保存下来。
下次更新的情况如下：
初始状态为100，update(num + 1)将num变为100 + 1 = 101。
update(num => num * 3)将num变为101 * 3 = 303。
可见，最终的结果303与「同步的React」是一致的，只是需要render两次。
「同步的React」 render一次，结果为303。
「并发的React」 render两次，结果分别为300(中间状态)，303(最终状态)。
从上例我们发现，组件render的次数受「有多少更新被跳过」影响，实际可能不止render两次，而是多次。
在老版「并发的React」中，表示「优先级」的是一个被称为expirationTime的时间戳。比较「更新是否应该被跳过」的算法如下：
复制
// 更新优先级是否小于render的优先级if (updateExpirationTime < renderExpirationTime) {
// ...被跳过
} else {
// ...不跳过
}
1.
2.
3.
4.
5.
6.
在这种逻辑下，只要优先级低，就会被跳过，就意味着多一次render。
在新版「并发的React」中，「优先级」被保存在「31位的二进制数」中。
举个例子：
复制
const renderLanes = 0b0101;u1.lane = 0b0001;u2.lane = 0b0010;
1.
2.
3.
其中renderLanes是本次更新指定的「优先级」。
比较「优先级」的函数为：
复制
function isSubsetOfLanes(set, subset) { return (set & subset) === subset;
}
1.
2.
3.
其中：
复制
// trueisSubsetOfLanes(renderLanes, u1.lane) // falseisSubsetOfLanes(renderLanes, u2.lane)
1.
2.
3.
4.
u1.lane包含于renderLanes中，代表这个更新拥有足够优先级。
u2.lane不包含于renderLanes中，代表这个更新没有足够优先级，被跳过。
但是「被跳过的更新」(例子中的u2)的lane会被重置为0，即：
复制
u2.lane = 0b0000;
1.
显然任何lanes都是包含0的：
复制
// trueisSubsetOfLanes(renderLanes, 0)
1.
2.
所以这个更新一定会在下次处理。换言之，在新版「并发的React」中，由于「优先级原因被跳过」，导致的「重复render」，最多只会有2次。
相比于老版「并发的React」，新版「并发的React」在render次数上会更有优势。
反映到用户的感官上，用户会更少看到「未计算完全的中间状态」。