乐趣区

关于前端:React-中-setState-是一个宏任务还是微任务

jiezi

最近有个敌人面试，面试官问了个奇葩的问题，也就是我写在题目上的这个问题。

能问出这个问题，面试官应该对 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;

页面大略长这样：

下面的 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)
  })
}

很显著，在点击 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('完结运行')
}

这么看，仿佛 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('完结运行')
  })
}

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

React 是如何管制 setState 的？

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

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

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

在调用栈中，能够看到 Component.setState 办法最终会调用 enqueueSetState 办法，而 enqueueSetState 办法外部会调用 scheduleUpdateOnFiber 办法，区别就在于失常调用的时候，scheduleUpdateOnFiber 办法内只会调用 ensureRootIsScheduled，在事件办法完结后，才会调用 flushSyncCallbackQueue 办法​。而脱离 React 事件流的时候，scheduleUpdateOnFiber 在 ensureRootIsScheduled 调用完结后，会间接调用 flushSyncCallbackQueue 办法，这个办法就是用来更新 state 并从新进行 render。

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();
    }
  }
}

所以，不论是间接调用 flushSyncCallbackQueue，还是推延调用，这里实质上都是同步的，只是有个先后顺序的问题。

将来会有异步的 setState

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

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

React 在两年前，降级 fiber 架构的时候，就是为其异步化做筹备的。在 React 18 将会正式公布 Concurrent 模式，对于 Concurrent 模式，官网的介绍如下。

什么是 Concurrent 模式？

Concurrent 模式是一组 React 的新性能，可帮忙利用放弃响应，并依据用户的设施性能和网速进行适当的调整。在 Concurrent 模式中，渲染不是阻塞的。它是可中断的。这改善了用户体验。它同时解锁了以前不可能的新性能。

当初如果想应用 Concurrent 模式，须要应用 React 的试验版本。如果你对这部分内容感兴趣能够浏览我之前的文章：《React 架构的演变 – 从同步到异步》。

退出移动版