前言

react 18 alpha 为了在用户体验下面获得停顿，做了不少的改变。

• startTransition 当状态变动须要消耗大量工夫的时候，保障 UI 有更好的响应
• useDeferredValue 让屏幕上不重要的一部分能够提早更新
• <SuspenseList> 能够让开发者管制加载进度条的显示程序
  上面是 react 外围员工 ricky 工作一年的过程和回顾。心愿通过他的形容，咱们对 react 新增的一些个性有更全面的理解。同时也能够对如何迭代一个大型开源我的项目领有个更近的视角。

ricky 的一年回顾

2021 年 6 月 10 日，react 外围开发者 ricky 回顾了在公布 react 18 阿尔法版之前一年内的心路历程。心愿通过这些形容让宽广开发者近距离的理解 react 外围团队是如何给 react 增加新个性的。

当我退出 react 团队的时候，他们曾经深入研究了并发个性 (concurrent) 好多年。我破费了大量工夫浏览和发问，来搞明确咱们曾经晓得了什么以及咱们将来如何布局。

因为我不足上下文，我开始次要是恪守团队的意见来发展工作。然而成为高级别的工程师的之后，我感觉很难再像之前那样了。我感觉是我本人曾经能够自主来推动 react 我的项目了。

侥幸的是，我和 acdlitte 一块共事。他曾经思考并发这个问题好多年了，并且曾经找到了很好的解决方案。过来一年中，咱们开始进行了大量 30 分钟的一对一沟通，最终演变成了两三个小时的深度探讨。这样的师徒关系让我感到太侥幸了。

团队曾经获得了很多的停顿。2019 年他们曾经开始了测试，然而在这个模型外面他们发现了一些缺点，而后又进行了齐全的从新设计实现。2020 年，acdlitte 实现了 lanes 的实现，所以我退出的时候，团队正着手并发 api 的设计和实现。

我接到的第一个工作是对于 startTransition 的，工作的目标是修复 react 和 scheduler 之间的分层问题。那时对 startTransition 的定义和当初不太一样。

当我刚开始钻研并发渲染的时候，ProvablyFlarnie 创立了一个叫做调度器（Scheduler）的包，来在浏览器工作和 react 渲染之间进行调度。调度器的设计思路是“用户代码给调度器设置优先级，react 利用优先级信息来进行更新”。

咱们思考应用像 startTransition 和 flushSync 这样的 React api，而不是间接调用调度程序。这样重写会很麻烦，并且有很多未知的货色，但它容许咱们在 React 18 中引入更简略的 api。

事实上，在重写泳道（lanes）之前，不可能做出——甚至不可能想到——这种扭转(这就是为什么从一开始就不是这样的)。但正如钻研中经常出现的，在一个畛域认识的扭转可能会引发对其余畛域的从新思考。

因为咱们曾经在产品中测试了现有的 api，所以咱们须要在不回归任何性能指标的状况下就地重写它。这意味着咱们须要让两个版本同时工作，并比拟咱们在 A / B 测试中所做的每一个扭转。

咱们十分侥幸可能在新的 Facebook 网站上进行钻研，因为它的工具和规模意味着咱们能够检测到性能上的十分小的变动，这可能意味着咱们的模型或实现中的缺点。

咱们也很侥幸能和 b56girard、alannorbauer 这样的人一起工作
他们帮忙咱们进行了正确的试验。并且当度量指标的时候，他们违心帮忙咱们找到 bug。

这个试验迭代对于 React 的胜利是至关重要的，因为这个阶段尽管可能会破费咱们几个月的工夫来修复找到的 bug。但如果咱们将这些 bug 推广到整个社区，几年也可能解决不完。

除了重写 React 外部代码外，咱们还须要对所有调用 Scheduler api(如 schedul.runwithpriority)的代码进行批改，并将它们更改为调用 React.startTransition、react.flushSync 这样的 api。

为了做到这一点，我手动查看了数百个应用旧 api 站点的用例，确认它在语义上是雷同的，更新它，记录咱们没有思考的用例，并与团队探讨这些用例。

咱们和应用 api 的工程师进行了大量探讨。我特地感 rhagigi，他负责许多外围基础设施的工作。并且当用例不分明的时候向我解释用例，他强烈主张放弃对用例的反对。

此间，我也和 sebmarkbage 谈了很多 react 设计相干的问题。我通知他为什么某个用例没有笼罩到，然而他通知我：“我的思考问题的形式是错的，应该依照正确（他的形式）的形式思考”。

在 react 开发团队，咱们的迭代形式是：提出个想法，大规模公布一些 api，看看运行的状况，查看测试用例，验证假如，迭代 api。如果，两头发现问题，咱们会从新开始新的一轮迭代。

在此期间，lunarruan 和 brian_d_vaughn 在钻研如何重构外围算法来触发副作用(effects)。这个重构很简单，然而对 Suspense 和 StrictMode 这样的新个性很要害。

当下面说的工作实现后，新个性的开发工作根本实现了。当初咱们思考采纳什么样的策略，来让 react 的 Concurrent 模块能够无缝降级。

对于如何平滑的降级到 Concurrent React，咱们有一些初步的想法。然而，咱们须要进行大量的代码批改，大量的观测来验证咱们的假如，并且确保新的改变不会升高性能，并反对所有的用例。

咱们做了很多批改，例如利用并发新个性来抉择工夫片，确保 react 事件零碎外部的事件和内部的事件同样的进行刷新。

在我重构调度器做的根底上，dan_abramov 实现了原生事件刷新。他做的十分好，原生事件刷新速度快了 5 倍，代码品质也高了 5 倍。(5+5=10 倍开发人员)。

有一次，咱们在 20 天内进行了 6 次试验，没有呈现任何重大回归问题(这很令人诧异，因为它蕴含了我的代码)。这极大地减速咱们的进度。两头取得的教训也让咱们决定选择性退出工夫片(time-slicing)。

到四月的时候，新 api 曾经足够稳固了，咱们曾经做好了公布 react 18 alpha 的筹备。然而因为 Suspense 和 batching 有一些语义下面的变动，咱们须要确保能够无痛降级能力进行公布。

为了验证咱们的新策略，咱们应用新策略降级了一些外部和内部的大型 app。这些 app 大范畴笼罩了咱们的用例，并且都没遇到什么大问题，甚至主动的批处理操作（automated batching)让他们中的一些有了性能的晋升。

这让咱们置信降级策略是牢靠的，咱们筹备公布新的 React 18alpha。

React 外围团队的工作是十分艰难的，有时候停顿也很迟缓。然而咱们必须要确保咱们提供的是社区须要的性能，让所有的用户有更好的体验，带来最小的破坏性变动，并且长期来看不存在太多的麻烦和斗争。

感激浏览! 往年是疯狂的一年，我心愿这篇文章能让你们理解到在 React 外围团队工作是什么感觉✨