面试官： React 17、18 的批量更新了解吗？

Ink
194 阅读4分钟

背景

最近对 react 的合并更新比较感兴趣，所以就研究了一下（整整 2 天！！！）

前言

这次主要是从调用栈中来进行分析，好，废话不多说，直接开始

案例

下面这个案例在 react17 和 react18 有不同的表现

import { useState } from 'react'

const App = () => {
  const [count, setCount] = useState(0)

  console.log('触发更新', count)

  const update111111111 = (c) => {
    console.log('1111');
    return c + 1
  }

  const update222222222 = (c) => {
    console.log('2222');
    return c + 1
  }

  const update333333333  = (c) => {
    console.log('33333');
    return c + 1
  }

  const handleClick = () => {
    // 同步setState
    setCount(update111111111)
    setCount(update222222222)
    setCount(update333333333)

    // 异步setState
    setTimeout(() => {
      setCount(count => {
        return count + 3
      })
      setCount(count => {
        return count + 3
      })
    })
  }
  
  return (
    <button className="btn" onClick={handleClick}>
      <span role="img" aria-label="react-emoji">⚛️</span> {count}
    </button>
  )
}


export default App

React 17 表现

在点击按钮后，可以看到页面的输出如下：

image.png

也就是这里触发了 3 次组件更新。

其中同步的 3 次 setState 被合并成了 1 次更新，异步的 2 次 setState 触发了 2 次组件更新

同步 setState 解析

给 更新 console 打个断点：

image.png

点击按钮后来看调用栈：

image.png

其中 renderWithHooks 这个函数会执行当前组件函数导致更新

这里因为 handleClick 中的 3 次同步 setState 执行完之后，executionContext 才被还原，在到达 finally 的时候，才会触发组件更新，所以这里 3 次 setState 只触发了一次组件更新（很简单对不对）

异步 setState 更新

给 更新 console 打个断点：

image.png

点击按钮，这里跳过一次断点，将同步 state 导致的更新的断点给跳过，然后进入到 setTimeout 中 setState 导致的更新

image.png

在执行 handleClick 中的 setTimout 任务时，discreteUpdates$1 函数已经执行完毕了，也就是此时的 executionContext 已经还原成 NoContext 了

setTimeout 中的更新在 scheduleUpdateOnFiber 函数中会被执行。这里有个 executionContext 的判断，由于 setTimeout 任务中的 executionContext 满足条件，所以这里会导致组件刷新（是不是也 So easy too happy）

经过上面的逻辑，我们就知道了在 React 18 之前，setTimeout 中的 state 都是同步更新的

又由于 setTimeout 中执行了 2 次 setState，所以这里就会触发 2 次组件更新。（如果在 class 组件里的话，这个 state 就是同步更新的，我们能直接获取最新的 state 值）

React 18 表现

这里的应用初始化方式用的 createRoot，在点击按钮后，可以看到页面的输出如下：

image.png

也就是这里只触发了 2 次组件更新，同步的 3 次 setState 被合并成了 1 次更新，异步的 2 次 setState 被合并成了 1 次更新

同步 setState 解析

首先来看点击按钮时的调用栈：

这里给 第一个 setCount 打一个断点

image.png

点击按钮，进入断点，断点进入 setState 内部查看，查看调用栈

image.png 图上有红字解析（某些红字不理解没关系，下面更新过程中会有解析）

这里点击函数执行前，对 executionContext 并入了 BatchedContext，代表属于此时属于批量更新上下文。然后在 finally 的时候对 executionContext 进行了还原（这里和 react 17 逻辑基本一样）

重点来了：我们知道在 handleClick 中，有 3 次 setState 都是同步的，所以在我们执行完 3 次 setState 后，这个 executionContext 才会进行还原

然后给 console 打个断点：

image.png

点击按钮，进行查看更新的调用栈：

image.png

scheduleMicrotask 为微任务调度的意思

可以看到这里组件更新的任务为微任务，其中 flushSyncCallbacks为组件更新函数入口。然后因为上面的 executionContext 的还原操作是属于同步的，所以在微任务执行后，executionContext 是为 NoContext 的，回调函数中的 flushSyncCallbacks 就可以正常执行，所以可以正常执行更新。

这就完成了一次批量更新，针对 3 次 setState 的结果，合并成了 1 次更新

异步 setState 更新

对 console 打断点：

image.png

然后点击按钮，跳过一次 同步 setState 导致的更新断点，来到 setTimeout 中 setState 导致的更新

来看下调用栈：

image.png

注：这里的 postMessage 也是宏任务的一种，使用的是 MessageChannel 的 port.postMessage 来进行的通信，是属于无延迟的一种宏任务。这里属于 schedule 开启了一个新的宏任务去处理新的 fiber render 的任务（感兴趣的可以去看看 react 内部 schedulePerformWorkUntilDeadline 方法的实现，会有几种方式选项逐一选择降级）

这里可以看到 setTimeout 的执行，在 flushWork（组件更新入口函数） 之前。那就意味着，setTimeout 中的 2 次 setState 计算完毕后，才会到 flushWork 执行，所以这就完成了 setTimeout 中的 2 次 setState 合并，只会触发一次更新

最后

看了网上比较多的帖子，感觉都讲的不是很清楚，所以还是决定自行研究一番，收获还是满满的

avatar
文章
阅读
粉丝