React 中 setState 是一个宏任务还是微任务？

深碍√TFBOYSˉ_ 2022-09-03 13:21 145阅读 0赞

点击上方 程序员成长指北，关注公众号

回复1，加入高级Node交流群

最近有个朋友面试，面试官问了个奇葩的问题，也就是我写在标题上的这个问题。

![41258504d02a48a8e403bce8a7fe68ae.png][]

能问出这个问题，面试官应该对 React 不是很了解，也是可能是看到面试者简历里面有写过自己熟悉 React，面试官想通过这个问题来判断面试者是不是真的熟悉 React ????。

## 面试官的问法是否正确？ ##

面试官的问题是，`setState` 是一个宏任务还是微任务，那么在他的认知里，`setState` 肯定是一个异步操作。为了判断 `setState` 到底是不是异步操作，可以先做一个实验，通过 CRA 新建一个 React 项目，在项目中，编辑如下代码：

import React from 'react';
    import logo from './logo.svg';
    import './App.css';
    
    class App extends React.Component {
      state = {
        count: 1000
      }
      render() {
        return (
          <div className="App">
            <img
              src={logo} alt="logo"
              className="App-logo"
              onClick={this.handleClick}
            />
            <p>我的关注人数：{this.state.count}</p>
          </div>
        );
      }
    }
    
    export default App;

页面大概长这样：

![90a6476ba2ef2833904449c26d0792e1.png][]

上面的 React Logo 绑定了一个点击事件，现在需要实现这个点击事件，在点击 Logo 之后，进行一次 `setState` 操作，在 set 操作完成时打印一个 log，并且在 set 操作之前，分别添加一个宏任务和微任务。代码如下：

handleClick = () => {
      const fans = Math.floor(Math.random() * 10)
      setTimeout(() => {
        console.log('宏任务触发')
      })
      Promise.resolve().then(() => {
        console.log('微任务触发')
      })
      this.setState({
        count: this.state.count + fans
      }, () => {
        console.log('新增粉丝数:', fans)
      })
    }

![acd5f4c6fc443772f5419099c5ddafe3.gif][]

很明显，在点击 Logo 之后，先完成了 `setState` 操作，然后再是微任务的触发和宏任务的触发。所以，`setState` 的执行时机是早于微任务与宏任务的，即使这样也只能说它的执行时机早于 `Promise.then`，还不能证明它就是同步任务。

handleClick = () => {
      const fans = Math.floor(Math.random() * 10)
      console.log('开始运行')
      this.setState({
        count: this.state.count + fans
      }, () => {
        console.log('新增粉丝数:', fans)
      })
      console.log('结束运行')
    }

![8c53140efb8005f4bb78b4cba22536c4.gif][]

这么看，似乎 `setState` 又是一个异步的操作。主要原因是，在 React 的生命周期以及绑定的事件流中，所有的 `setState` 操作会先缓存到一个队列中，在整个事件结束后或者 mount 流程结束后，才会取出之前缓存的 `setState` 队列进行一次计算，触发 state 更新。只要我们跳出 React 的事件流或者生命周期，就能打破 React 对 `setState` 的掌控。最简单的方法，就是把 `setState` 放到 `setTimeout` 的匿名函数中。

handleClick = () => {
      setTimeout(() => {
        const fans = Math.floor(Math.random() * 10)
        console.log('开始运行')
        this.setState({
          count: this.state.count + fans
        }, () => {
          console.log('新增粉丝数:', fans)
        })
        console.log('结束运行')
      })
    }

![eac64f4539ed58b75bbfc7f004f7f111.gif][]

所以，`setState` 就是一次同步行为，根本不存在面试官的问题。

## React 是如何控制 setState 的 ？ ##

前面的案例中，`setState` 只有在 `setTimeout` 中才会变得像一个同步方法，这是怎么做到的？

handleClick = () => {
      // 正常的操作
      this.setState({
        count: this.state.count + 1
      })
    }
    handleClick = () => {
      // 脱离 React 控制的操作
      setTimeout(() => {
        this.setState({
          count: this.state.count + fans
        })
      })
    }

先回顾之前的代码，在这两个操作中，我们分别在 Performance 中记录一次调用栈，看看两者的调用栈有何区别。

![f0a74d7fd0ab501140747cff9c495aa1.png][] 正常操作 ![089a9406a50c6334c4b7c8eab227145e.png][] 脱离 React 控制的操作

在调用栈中，可以看到 `Component.setState` 方法最终会调用 `enqueueSetState` 方法，而 `enqueueSetState` 方法内部会调用 `scheduleUpdateOnFiber` 方法，区别就在于正常调用的时候，`scheduleUpdateOnFiber` 方法内只会调用 `ensureRootIsScheduled` ，在事件方法结束后，才会调用 `flushSyncCallbackQueue` 方法。而脱离 React 事件流的时候，`scheduleUpdateOnFiber` 在 `ensureRootIsScheduled` 调用结束后，会直接调用 `flushSyncCallbackQueue` 方法，这个方法就是用来更新 state 并重新进行 render 。

![c825c34c15aa328498e74521d55fe6fa.png][] ![ceb2e1219b8b62a7c862e2262964f14b.png][]

function scheduleUpdateOnFiber(fiber, lane, eventTime) {
      if (lane === SyncLane) {
        // 同步操作
        ensureRootIsScheduled(root, eventTime);
        // 判断当前是否还在 React 事件流中
        // 如果不在，直接调用 flushSyncCallbackQueue 更新
        if (executionContext === NoContext) {
          flushSyncCallbackQueue();
        }
      } else {
        // 异步操作
      }
    }

上述代码可以简单描述这个过程，主要是判断了 `executionContext` 是否等于 `NoContext` 来确定当前更新流程是否在 React 事件流中。

众所周知，React 在绑定事件时，会对事件进行合成，统一绑定到 `document` 上（ `react@17` 有所改变，变成了绑定事件到 `render` 时指定的那个 DOM 元素），最后由 React 来派发。

所有的事件在触发的时候，都会先调用 `batchedEventUpdates$1` 这个方法，在这里就会修改 `executionContext` 的值，React 就知道此时的 `setState` 在自己的掌控中。

// executionContext 的默认状态
    var executionContext = NoContext;
    function batchedEventUpdates$1(fn, a) {
      var prevExecutionContext = executionContext;
      executionContext |= EventContext; // 修改状态
      try {
        return fn(a);
      } finally {
        executionContext = prevExecutionContext;
      // 调用结束后，调用 flushSyncCallbackQueue
        if (executionContext === NoContext) {
          flushSyncCallbackQueue();
        }
      }
    }

![e03045237f643d9c231419a66be53d9b.png][]

所以，不管是直接调用 `flushSyncCallbackQueue` ，还是推迟调用，这里本质上都是同步的，只是有个先后顺序的问题。

## 未来会有异步的 setState ##

如果你有认真看上面的代码，你会发现在 `scheduleUpdateOnFiber` 方法内，会判断 `lane` 是否为同步，那么是不是存在异步的情况？

React 在两年前，升级 fiber 架构的时候，就是为其异步化做准备的。在 React 18 将会正式发布 `Concurrent` 模式，关于 `Concurrent` 模式，官方的介绍如下。

![3f2988fb7b9e9fb51b28b6c3a5db669b.png][]

> **什么是 Concurrent 模式？**
> 
> Concurrent 模式是一组 React 的新功能，可帮助应用保持响应，并根据用户的设备性能和网速进行适当的调整。在 Concurrent 模式中，渲染不是阻塞的。它是可中断的。这改善了用户体验。它同时解锁了以前不可能的新功能。

**如果觉得这篇文章还不错**

**点击下面卡片关注我**

**来个【分享、点赞、在看】三连支持一下吧![29dedb966c4d2d021d06a504f3778e41.png][]**

![4d07c35dcd6f480b1b0e070f0416dc50.png][]

**“分享、点赞、在看” 支持一波** ![7cf016b24a896774b27be21b4d867793.png][]

[41258504d02a48a8e403bce8a7fe68ae.png]: /images/20220829/d6a85a5e8a2d4c50ad23267086fba309.png
[90a6476ba2ef2833904449c26d0792e1.png]: /images/20220829/f1b4a52d89ac4b31aeb47d35090a1fa9.png
[acd5f4c6fc443772f5419099c5ddafe3.gif]: /images/20220829/0b54f3b9da4b4b3183ca3eedc758e709.png
[8c53140efb8005f4bb78b4cba22536c4.gif]: /images/20220829/907c1502ffdf4cb991e2f23060a0b6bf.png
[eac64f4539ed58b75bbfc7f004f7f111.gif]: /images/20220829/cab33160b8f341fd932e06635a4dc5e6.png
[f0a74d7fd0ab501140747cff9c495aa1.png]: https://img-blog.csdnimg.cn/img_convert/f0a74d7fd0ab501140747cff9c495aa1.png
[089a9406a50c6334c4b7c8eab227145e.png]: /images/20220829/aedfc11e5a72439f95ee31ae11cc61ff.png
[c825c34c15aa328498e74521d55fe6fa.png]: https://img-blog.csdnimg.cn/img_convert/c825c34c15aa328498e74521d55fe6fa.png
[ceb2e1219b8b62a7c862e2262964f14b.png]: /images/20220829/a5314568e1c6492fa375347e1d3016cc.png
[e03045237f643d9c231419a66be53d9b.png]: /images/20220829/64f5bce1c4bf412aa58c8edc84af4ef5.png
[3f2988fb7b9e9fb51b28b6c3a5db669b.png]: /images/20220829/2b336ca07ccf4d178501c151a4eb7495.png
[29dedb966c4d2d021d06a504f3778e41.png]: /images/20220829/18824c23ff174ecca6ff00df016f962f.png
[4d07c35dcd6f480b1b0e070f0416dc50.png]: /images/20220829/227ba33c040f4094ae45a080450ed08e.png
[7cf016b24a896774b27be21b4d867793.png]: /images/20220829/a9ad6546adff47f792bf047ab2114346.png