React18正式引入了对并发模式/特性的[渐进升级]策略

React18把重点放在解决兼容性和如何做迁移的问题上,自从Concurrent Mode(并发模式)

core team成员每天在推上Github上[XXX isnotCM-safe]吓死个人,使得整个社区都暗自一直担心未来的React是不是会为了上CM直接breaking change

然后不兼容CM的代码必须要全部迁移过来才能用CM('all-or-nothing'upgrade strategy)

这次十八得发布终于横扫了大家的担忧 并发的引入将会是opt-in 不用的话就没有breaking changes 整体采用了渐进升级的策略

1.React团队对'Concurrency opt-in'roots的兼容性做了很多优化-如果不用CM特性的话大概率能just works 从此再无CM,只有Concurrent Features(并发特性)

2.对于直接想让应用的某一部分[躺平]的可以用legacy root-对系统的修改目的之一就是为了让你的React应用同事可以跑在不同的版本上

18的实际做法是引入了新的Root API ReactDOM.createRoot来与旧的ReactDOM.render API区分开来

你可以将整个React树分形成不同的roots,用旧的API的legacy roots会跑在[legacy mode 传统模式]上(相当于跑在17上) 用新API的roots会跑在 'Concurrency opt-in' roots下

React 18 的其他新特性

1.更加激进的[自动batching]------React 17只在事件回调中batch,React 18则会对任何来源的setState做尽可能多的batching

2.新的 useDeferredValue API------本质上都是允许你将UI的一部分标记为较低的[更新优先级]

3.Suspense SSR------完全用React重写的Facebook.com是用Hermes做SSP来优化首屏渲染的,所以SSR的优化就成为了React团队的优先级之一啦......但是传统的SSR有一个问题就是全量渲染的延迟太高了,而CM+Suspence就可以做到用Suspence boundary将应用分片,然后以此为单位做流式SSR.

4.StrictMode在继double-render之后加入了double-effect------可以看到,随着CM的逐渐落地,其[底层能力]的一面终于开始逐渐显著出来,越来越多的上层应用会发布(Brian提到的Offscreen API以及RN Pre-render)