关于react.js:面试官react中的setState是同步的还是异步的

38次阅读

共计 4196 个字符,预计需要花费 11 分钟才能阅读完成。

hello,这里是潇晨,大家在面试的过程是不是常常会遇到这样的问题,react 的 setState 是同步的还是异步的,这个问题答复的时候肯定要残缺,来看上面这几个例子:

例子 1:点击 button 触发更新,在 handle 函数中会调用两次 setState

export default class App extends React.Component {
  state = {num: 0,};
  updateNum = () => {console.log("before", this.state.num);

    this.setState({num: this.state.num + 1});
    this.setState({num: this.state.num + 1});
    console.log("after", this.state.num);

  };
  render() {const { num} = this.state;
    console.log("render", num);
    return <button onClick={this.updateNum}>hello {num}</button>;
  }
}

// 打印后果
//render     0
//before     0
//after     0
//render     1

例子 2: 例子 1 的两次 setState 在 setTimeout 回调中执行

export default class App extends React.Component {
  state = {num: 0,};
  updateNum = () => {console.log("before", this.state.num);

    setTimeout(() => {this.setState({ num: this.state.num + 1});
        this.setState({num: this.state.num + 1});
        console.log("after", this.state.num);
    }, 0);
  };
  render() {const { num} = this.state;
    console.log("render", num);
    return <button onClick={this.updateNum}>hello {num}</button>;
  }
}

// 打印后果
//render     0
//before     0
//render     1
//render     2
//after     2

例子 3: 用 unstable_batchedUpdates 在 setTimout 中执行,unstable_batchedUpdates 的回调函数中调用两次 setState

import {unstable_batchedUpdates} from "react-dom";

export default class App extends React.Component {
  state = {num: 0,};
  updateNum = () => {console.log("before", this.state.num);

    setTimeout(() => {unstable_batchedUpdates(()=>{this.setState({ num: this.state.num + 1});
        this.setState({num: this.state.num + 1});
        console.log("after", this.state.num);
      })
    }, 0);
  };
  render() {const { num} = this.state;
    console.log("render", num);
    return <button onClick={this.updateNum}>hello {num}</button>;
  }
}

// 打印后果
//render     0
//before     0
//after     0
//render     1

例子 4: 两次 setState 在 setTimeout 回调中执行,然而用 concurrent 模式启动,也就是调用 ReactDOM.unstable_createRoot 启动利用。

import React from "react";
import ReactDOM from "react-dom";

export default class App extends React.Component {
  state = {num: 0,};
  updateNum = () => {console.log("before", this.state.num);

    setTimeout(() => {this.setState({ num: this.state.num + 1});
        this.setState({num: this.state.num + 1});
        console.log("after", this.state.num);
    }, 0);
  };
  render() {const { num} = this.state;
    console.log("render", num);
    return <button onClick={this.updateNum}>hello {num}</button>;
  }
}

ReactDOM.unstable_createRoot(rootEl).render(<App />);

// 打印后果
//render     0
//before     0
//after     0
//render     1

batchedUpdates

简略来说,在一个上下文中同时触发屡次更新,这些更新会合并成一次更新,例如

onClick() {this.setState({ count: this.state.count + 1});
  this.setState({count: this.state.count + 1});
}

​ 在之前的 react 版本中如果脱离以后的上下文就不会被合并,例如把屡次更新放在 setTimeout 中,起因是处于同一个 context 的屡次 setState 的 executionContext 都会蕴含 BatchedContext,蕴含 BatchedContext 的 setState 会合并,当 executionContext 等于 NoContext,就会同步执行 SyncCallbackQueue 中的工作,所以 setTimeout 中的屡次 setState 不会合并,而且会同步执行。

onClick() {setTimeout(() => {this.setState({ count: this.state.count + 1});
    this.setState({count: this.state.count + 1});
  });
}
export function batchedUpdates<A, R>(fn: A => R, a: A): R {
  const prevExecutionContext = executionContext;
  executionContext |= BatchedContext;
  try {return fn(a);
  } finally {
    executionContext = prevExecutionContext;
    if (executionContext === NoContext) {resetRenderTimer();
       //executionContext 为 NoContext 就同步执行 SyncCallbackQueue 中的工作
      flushSyncCallbackQueue();}
  }
}

​ 在 Concurrent mode 下,下面的例子也会合并为一次更新,根本原因在如下一段简化的源码,如果屡次 setState,会比拟这几次 setState 回调的优先级,如果优先级统一,则先 return 掉,不会进行前面的 render 阶段

相干参考视频解说:进入学习

function ensureRootIsScheduled(root: FiberRoot, currentTime: number) {
  const existingCallbackNode = root.callbackNode;// 之前曾经调用过的 setState 的回调
  //...
    if (existingCallbackNode !== null) {
    const existingCallbackPriority = root.callbackPriority;
    // 新的 setState 的回调和之前 setState 的回调优先级相等 则进入 batchedUpdate 的逻辑
    if (existingCallbackPriority === newCallbackPriority) {return;}
    cancelCallback(existingCallbackNode);
  }
    // 调度 render 阶段的终点
    newCallbackNode = scheduleCallback(
    schedulerPriorityLevel,
    performConcurrentWorkOnRoot.bind(null, root),
  );
    //...
}

​ 那为什么在 Concurrent mode 下,在 setTimeout 回调屡次 setState 优先级统一呢,因为在获取 Lane 的函数 requestUpdateLane,只有第一次 setState 满足 currentEventWipLanes === NoLanes,所以他们的 currentEventWipLanes 参数雷同,而在 findUpdateLane 中 schedulerLanePriority 参数也雷同(调度的优先级雷同),所以返回的 lane 雷同。

export function requestUpdateLane(fiber: Fiber): Lane {
    //...
  if (currentEventWipLanes === NoLanes) {// 第一次 setState 满足 currentEventWipLanes === NoLanes
    currentEventWipLanes = workInProgressRootIncludedLanes;
  }
  //...
  // 在 setTimeout 中 schedulerLanePriority, currentEventWipLanes 都雷同,所以返回的 lane 也雷同
  lane = findUpdateLane(schedulerLanePriority, currentEventWipLanes);
  //...

  return lane;
}

总结:

legacy 模式下:命中 batchedUpdates 时是异步 未命中 batchedUpdates 时是同步的

concurrent 模式下:都是异步的

正文完
 0