React 中的 setState 是同步还是异步

setState 是同步还是异步?肯定是异步的呀。

确定么?那看一下这段代码会打印什么:

import { Component } from 'react';
class Dong extends Component {
    constructor() {
        super();
        this.state = {
            count: 0
        }
    }
    componentDidMount() {
        setTimeout(() => {
            this.setState({
                count: 1
            });
            console.log(this.state.count);
            this.setState({
                count: 2
            });
            console.log(this.state.count);
        });
    }
    render() {
        console.log('render:', this.state.count);
        return <div>{this.state.count}</div>;
    }
}

在 setTimeout 里修改了两次 state,并打印了 state 的值。如果是异步的,那应该打印的时候 count 还没修改,依然是 0,所以打印两次 0。然后初始化渲染一次,setState 后再渲染一次,应该 render 两次,count 分别为 0 和 2。按照异步的方式来分析,确实应该是这样的。

我们执行一下:

会发现两次打印分别是 1 和 2,也就是说 setState 同步修改了 state,然后每次都触发了渲染,所以一共 render 3 次,分别是 0、1、2。

那这么说 setState 是同步的?确定么?那看下这段代码会打印什么?

class Dong extends Component {
    constructor() {
        super();
        this.state = {
            count: 0
        }
    }
    componentDidMount() {
        this.setState({
            count: 1
        });
        console.log(this.state.count);
        this.setState({
            count: 2
        });
        console.log(this.state.count);
        this.setState({
            count: 3
        });
        console.log(this.state.count);
    }
    render() {
        console.log('render:', this.state.count);
        return <div>{this.state.count}</div>;
    }
}

如果 setState 是同步的,那执行完就会修改 state,应该分别打印 1、2、3,然后触发三次 render,加上最开始的一次,一共四次,打印 0、1、2、3。

我们来执行一下:

三次打印都是 0,这说明 setState 是异步的。而且三次 setState 只触发了一次 render,加上最开始的 render,一共两次,打印 0、3。

什么鬼,怎么又是异步的了?

而且不止 class 组件的 setState 是这样,换成 function 组件的 useState 也是一样的:

比如修改三次 state,只会 render 一次:

而在 setTimeout 里,每次修改 state 都会 render:

是不是有点晕,什么情况下 setState 是同步的,什么情况下是异步的呢?这要从源码找答案了,我们来读一下 setState 的源码。

首先理一下 React 渲染的流程:

React 渲染流程

react 通过 jsx 来描述界面,jsx 可以通过 babel 等编译器编译成 render function,然后执行后产生 vdom:

这个 vdom 也不是直接渲染的,而是会先转化为 fiber,之后再渲染。因为 vdom 里每个节点只记录了子节点(children),没有记录兄弟节点,所以必须一次性渲染完,不能打断。而转成 fiber 的链表结构就会记录父节点(return)、子节点(child)、兄弟节点(sibling),就变成了可打断的。

这里的 vdom 是 React Element 对象:

转化为 fiber 之后是 FiberNode 的对象:

从 vdom 转换成 fiber 的过程就叫做 reconcile,转换过程中会顺便创建对应的 dom 元素,然后全部转换完后一次性 commit 到 dom。这个过程不是一次性的,是通过 scheduler 调度执行的,那也就可以分批次进行,也就是可打断的含义。这就是 React 的 fiber 架构下的渲染流程。理论说完了,我们来对应到源码看一下(这里看的是 v17 的源码):

react 把 schedule 和 reconcile 叫做 render 阶段,这个阶段就是把 vdom 转为 fiber。(schedule 只是让 reconcile 可以分多次执行,可以打断,但做的事情是不变的,所以 schedule 也是 render 阶段的一部分)

之后把 fiber 更新到 dom 的过程就叫做 commit 阶段。

对应到源码里就是这样的:

这个 performSyncWorkOnRoot 就是渲染的入口,就像之前所说的,会先执行 render 阶段,把 vdom 转成 fbier,然后再执行 commit,更新到 dom。

render 阶段会执行一个调度的 loop:

这个 loop 就是不断地处理一个个 fiber 的 reconcile:

每个节点都有 beginWork 和 completeWork 两个阶段,因为要做 vdom 转 fiber,而 vdom 是一个树形结构,需要递归处理:

具体不同节点的 reconcile 逻辑不同:

比如函数组件会被调用,拿到 render 出的 vdom 继续进行 reconcile:

比如 class 组件会创建实例,调用 render 方法,拿到 vdom,然后再继续 renconcileChildren。

总之,vdom 转 fiber 是一个递归进行的过程。之后再进行 commit 阶段。整个渲染流程的入口就是 performSyncWorkOnRoot 函数。渲染的流程讲完了,接下来就是 setState 怎么触发渲染的流程了:

setState 的流程

我们知道了渲染的入口就是 performSyncWorkOnRoot 函数,那 setState 修改完状态,触发一下这个函数不就行了?

确实是这样的。setState 会调用 dispathAction,创建一个 update 对象放到 fiber 节点的 updateQueue 上,然后调度渲染:

调度更新自然就是调度上面说的那个 performSyncWorkOnRoot 函数:react 会先从触发 update 的 fiber 往上找到根 fiber 节点,然后再调用 performSyncWorkOnRoot 的函数进行渲染:

这就是 setState 之后触发重新渲染的实现。而 setState 是同步还是异步,也就是在这一段控制的。我们看到判断条件里有个 excutionContext,这个是用来标识当前环境的,比如是批量还是非批量,是否执行过 render 阶段、commit 阶段。

其实在 ReactDOM.render 执行的时候会先调用 unbatchUpdates 函数:

这个函数会在 excutionContext 中设置一个 unbatach 的 flag:

这样在 update 的时候,就会立刻执行 performSyncWorkOnRoot 来渲染。因为首次渲染的时候是马上就要渲染的,没必要调度。

之后走到 commit 阶段会设置一个 commit 的 flag:

然后再次 setState 就不会走到 unbatch 的分支了。那为什么 setTimeout 里面的 setState 会同步执行呢?

因为直接从 setTimeout 执行的异步代码是没有设置 excutionContext 的,那就会走到 NoContext 的分支,会立刻渲染。

(这里的 flush 最终会调用 performSyncWorkOnRoot 函数来渲染):

有什么办法能让 setTimeout 里执行的函数也有 excutionContext 呢?其实 react17 暴露了 batchUpdates 的 api,用它包裹下,里面的 setState 就会批量执行了:

它的源码其实就是设置了下 excutionContext:

这样等 setState 全部执行完之后再 flush,调用 peformSyncWorkOnRoot 渲染,效果就是批量的 setState 了。其实按理来说 setState 不能叫异步,还是在同一个调用栈执行的,只不过顺序不同而已。只能叫批量还是非批量。

在 react17 中是这么处理的,如果是 react18,使用 createRoot 的 api 的话,就不会有这种问题了,就算是 setTimeout 里的代码也能批量执行,

而且为了兼容 react17 这种情况,还做了特殊处理,当没有开启并发模式,也就是还是用 ReactDOM.render 的 api 时,没有指定 excutionContext 还会立刻渲染:

等 react 18 普及以后,所有的 setState 都是批量的了,就不会再有批量还是非批量的问题。

总结

虽然我们讨论的是 setState 的同步异步,但这个不是 setTimeout、Promise 那种异步,只是指 setState 之后是否 state 马上变了,是否马上 render。

我们梳理了下 React 的渲染流程,包括 render 阶段、commit 阶段,render 阶段是从 vdom 转 fiber,包含 schedule 和 reconcile,commit 阶段是把 fiber 更新到 dom。渲染流程的入口是 performSyncWorkOnRoot 函数。setState 会创建 update 对象挂到 fiber 对象上,然后调度 performSyncWorkOnRoot 重新渲染。

在 react17 中,setState 是批量执行的,因为执行前会设置 executionContext。但如果在 setTimeout、事件监听器等函数里,就不会设置 executionContext 了,这时候 setState 会同步执行。可以在外面包一层 batchUpdates 函数,手动设置下 excutionContext 来切换成异步批量执行。

在 react18 里面,如果用 createRoot 的 api,就不会有这种问题了。setState 是同步还是异步这个问题等 react18 普及以后就不会再有了,因为所有的 setState 都是异步批量执行了。

到此这篇关于React 中的 setState 是同步还是异步的文章就介绍到这了,更多相关React setState 内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • React中setState同步异步场景的使用

    目录 setState同步异步场景 描述 原理 保证内部数据统一 启用并发更新 参考 setState同步异步场景 React通过this.state来访问state,通过this.setState()方法来更新state,当this.setState()方法被调用的时候,React会重新调用render方法来重新渲染UI.相比较于在使用Hooks完成组件下所需要的心智负担,setState就是在使用class完成组件下所需要的心智负担,当然所谓的心智负担也许叫做所必须的基础知识更加合适一些.

  • React中setState的使用与同步异步的使用

    在react中,修改状态如果直接使用this.state,不会引起组件的重新渲染,需要通过 this.setState来对组件的属性进行修改. 1.this.setState的两种定义方式 定义初始状态 state = { count: 0 }, 如果此时有一个按钮,点击按钮让计数加1,我们可以有两种写法 (1)传递对象 this.setState({ count: this.state.count + 1}) (2)传递函数 this.setState((state, props) => ({

  • 代码解析React中setState同步和异步问题

    React起源于Facebook的内部项目.React的出现是革命性的创新,React的是一个颠覆式的前端框架.在React官方这样介绍的它:一个声明式.高效.灵活的.创建用户界面的JavaScript库,即使React的主要作用是构建UI,但是项目的逐渐成长已经使得react成为前后端通吃的WebApp解决方案. angular中用的是watcher对象,vue是观察者模式,react就是state了,他们各有各的特点,没有好坏之分,只有需求不同而选择不同. React的官方网址:https:

  • 关于React中setState同步或异步问题的理解

    目录 1. setState同步?异步? 2. 表现为异步 1. React 合成事件 2. 生命周期函数 3. 表现为同步 1. 原生事件 2. setTimeout 4. setState的第二个参数 1. setState同步?异步? 在 React 的类式组件中,我们可以使用setState方法更新state状态.但有些时候使用setState之后,得不到最新的数据. 其实 React 中setState本身执行的过程和代码是同步的,只是因为 React 框架本身的性能优化机制而导致的.

  • React 中的 setState 是同步还是异步

    setState 是同步还是异步?肯定是异步的呀. 确定么?那看一下这段代码会打印什么: import { Component } from 'react'; class Dong extends Component { constructor() { super(); this.state = { count: 0 } } componentDidMount() { setTimeout(() => { this.setState({ count: 1 }); console.log(this

  • jQuery中的ajax async同步和异步详解

    项目中有这样一个需求,使用ajax加载数据返回页面并赋值,然后前端取出该值 这其中涉及到代码的顺序问题,有时后台还未返回数据,但已执行后面代码, 所以就会造成取不到值 $.ajax({ type: "post", url: "admin/PfmOptionRuleItem.do", success: function(data){ $("#ruleItem").val(data.ruleItem); //① } }); return $(&quo

  • node.js中的forEach()是同步还是异步呢

    node里几乎所有用到回调函数的地方,都是异步的,回调函数后面的代码很可能比回调函数中的代码后先执行,特别是数据库操作.当然,node也提供了同步版本的函数,例如文件操作,fs.readFileSync()是fs.readFile()的同步版本. 那么问题来了,forEach()是不是异步的呢?按理说,没有加Sync,应该是异步的呀. 复制代码 代码如下: var arr = ['a', 'b', 'c'];  var str = '123';  arr.forEach(function(ite

  • React 中 setState 的异步操作案例详解

    目录 前言 React 中的 setState 为什么需要异步操作? 什么时候setState会进行同步操作? 前言 在使用state的时候, 如果我们企图直接修改state中的某一个值之后直接打印(使用)他,就会发现,他其实并没有改变. 就像下面的例子,企图通过点击事件之后就使用修改之后的state的值,但是会发state中的并没有被立即修改,还是原先的值,我们都知道那是因为 setState就相当于是一个异步操作,不能立即被修改. import React, { Component } fr

  • 详细谈谈React中setState是一个宏任务还是微任务

    目录 前言 面试官的问法是否正确?§ React 是如何控制 setState 的 ?§ 未来会有异步的 setState§ 总结 前言 最近有个朋友面试,面试官问了个奇葩的问题,也就是我写在标题上的这个问题. 能问出这个问题,面试官应该对 React 不是很了解,也是可能是看到面试者简历里面有写过自己熟悉 React,面试官想通过这个问题来判断面试者是不是真的熟悉 React

  • 解决react中useState状态异步更新的问题

    目录 疑惑 状态异步更新带来的问题 问题示例 问题解决 类组件的解决方案 函数组件的解决方案 其他解决方案 结尾 疑惑 相信刚开始使用react函数组件的小伙伴也遇到过一个坑,就是 useState 更新状态是异步更新的,但是react 并没有提供关于这个问题的解决方案.那我们能否使用自己的方法来解决这个问题呢?答案肯定是可以的. 状态异步更新带来的问题 就拿一个比较常见的场景来说.在react项目中,我们想在关闭对话框后再去处理其他业务.但是 useState 的状态是异步更新的.我们通过se

随机推荐