React 18——记录

自动批量更新

在React18之前，React 只会在事件处理程序中进行批量更新。在Promise,setTimeout及本地事件处理程序中，在React18之前，是不会进行批量更新的。

但在React18中，在concurrent模式中，无论更新来自哪里，都会进行批量处理。

如果不想进行批量更新，在18中，也有相应的api提供支持：flushSync

SSR 支持Suspense

继续支持renderToString,部分支持Suspense的功能
弃用了renderTONodeStream，
启用新apipipeToNodeWritable,完全支持Suspense功能

Suspense 机制更新

暂且称18以前的Suspense 为Legacy Suspense,
18以后的为Concurrent Suspense

下面是一个相关的场景说明：

const  refChild  =  useRef ( null ) 

}>

在17中，Child 组件会挂载到DOM上，并触发相关的副作用或生命周期
在18 中，Child组件不会挂载到DOM上，其副作用、生命周期也不会再Parent解决阻塞之前触发

在 17中，refChild.current在Parent 解决之前，将在初始渲染时立即指向 DOM 节点。
在18中，refChild.current在 Parent 解决并且 Suspense 边界未阻塞之前将为 null。

在这里的话，在升级的时候，对于以前涉及的相关代码，可能需要注意一下。

Concurrent模式及其功能

在Concurrent模式下，正式支持：

useTransition
useDeferredValue
SuspensList

useTransition

场景：
存在tab A 和 tab B ，用户目前在A，点击跳转到 B。

交互路径一:
    直接跳转到tab B,用户在loading阶段等待。tab A 不可见，也无其他相应和交互，用户体验不好

交互路径二:
    用户在tab A 等待，等tab B加载完后，再跳转到B。此时没有一些交互反馈，用户不知道发生了什么，用户体验更差。
 交互路径三：
    用户在tab A 等待，等tab B加载完后，再跳转到B，期间有loading 提示 tabB 的加载情况。用户体验较好。

与setTimeout区别:
useTransition不像setTimeout那样被安排在稍后的时间。它是立即执行的。立即执行后，被useTransition包裹的更新被当作非紧急事件来处理，被打上transition这样的标志，

useDeferredValue

这让我们可以立即显示 input 的新文本，从而感觉到网页的响应。同时，MySlowList “延后” 几秒，根据 timeoutMs ，更新之前，允许它在后台渲染当前文本。

与 Transition 机制类似，相当于延迟状态更新，在新数据准备好之前，可以继续沿用旧数据，如果 1 秒内新数据来了，（从旧内容切换到）显示新内容，否则立即更新状态，该 loading 就 loading

与 Transition 的区别在于，useDeferredValue是面向状态值的，而 Transition 面向状态更新操作，算是 API 及语义上的差异，机制上二者非常相像

SuspensList

提供SuspenseList 来控制 Suspense内容的渲染顺序，来保证列表中元素的显示顺序按相对位置来，来避免内容被挤下去。

在1中：如果你持续的刷新，你会发现有的时候文章列表会先到达，有的时候“趣闻”会先到达

在2中：现在我们总是要等待这两个数据都获取到之后，如果其中一个先到达到，还需要等待另一个

在3中：这个 revealOrder="forwards" 配置表示这个列表中最接近的只会根据在树中的显示顺序来“展开”它们的内容 — 即使它们的数据在不同的顺序到达。

16329919146704.jpg

16329919376379.jpg

16329919525187.jpg

参考

Concurrent UI 模式 (试验阶段)

React useTransition