前言

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外围团队工作是什么感觉✨