官博解读：React18真的来了三条官方消息在React18工作计划[1]的博文中，官方带来了三条消息。1.v18的工作已经在进行中，将是下一个主要版本2.v18工作组的创建是为了让社区专家、开发人员和库作者首先尝试v18，并预兼容CM（并发模式），教育社区准备工作组地址[2]3.发布v18Alpha版本，让图书馆作者可以尝试使用v18Alpha进行反馈[3]接下来，我们来解读消息背后的信息。踏脚石是什么？我们知道v17是稳定CM的“敲门砖”版本。CM难以稳定的原因可以用一句话来概括：CM给React带来了应用级的BreakingChange，而且是史无前例的。这里的工作量包括两部分：支持v18新特性所支付的开发成本，帮助社区逐步升级v18所支付的开发和沟通成本新特性所支付的开发成本v18主要特性“StreamingSSR”预依赖关于“不同优先级的悬念”。“不同优先级的悬念”预先依赖于“更灵活的CM”。这里的灵活是指“优先级”既可以独立比较，也可以在“批”的概念中相互比较。因此，“安德鲁”需要在v16.13.1完成车道优先级调度算法的开发。同时，在底层支持“更灵活的CM”后，也向上层带来了startTransition、useDeferredValue等API，让开发者可以明确指定UI渲染的优先级。例如：useDeferredValue可以用来实现根据用户设备性能（qps）自动去抖功能。新的API，比如OffScreen（可以理解为React版的keep-alive），自动batchUpdate，不局限于事件回调函数。社区逐步升级所付出的成本也在最新进展中披露。不会或很快升级到v18对现有代码的最小更改。原因是：CM是可选的（即默认关闭“时间分片”）。刚才讲到，CM前端依赖于“优先级调度”，“优先级调度”是在“时间分片”架构上实现的。因此，在默认关闭“时间分片”的情况下，现有代码几乎无需改动即可顺利升级到v18。可以看出，“时间分片”特性被标记为Umbrella，这意味着该特性将影响到很多API、架构和库。v17发布时，React内部重构了“事件机制”。React事件不会向上冒泡到一个统一的根节点，而是向上冒到各个应用的根节点（即调用ReactDOM.render的节点）。这样可以让整个应用的一部分保持现有的legacy模式，而新的部分启用CM，因为两个子应用是相互独立的。由于CM带来的BreakingChange使得大量的库不兼容（比如mobx），React还专门开发了一个新的API——create-subscription用于订阅外部依赖。这就是为什么v18Alpha将优先考虑库作者的原因——当启用完整的CM功能时，库的现有实现可能不兼容。当前的v18Alpha版本此时可用。公共测试版将在几个月后发布。测试版发布几周后，将发布RC版本。最后，至少在RC发布几周后，发布稳定版本。所以总体预测是：v18稳定版会在年底到来。届时，React团队的重点将放在服务器组件上。参考文献[1]React18工作计划：https://reactjs.org/blog/2021/06/08/the-plan-for-react-18.html[2]工作组地址：https://github.com/reactwg/react-18/discussions[3]使用v18Alpha：https://github.com/reactwg/react-18/discussions/9
