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 的值。

如果是異步的，那應(yīng)該打印的時候 count 還沒修改，依然是 0，所以打印兩次 0。

然后初始化渲染一次，setState 后再渲染一次，應(yīng)該 render 兩次，count 分別為 0 和 2。

按照異步的方式來分析，確實應(yīng)該是這樣的。

我們執(zhí)行一下：

會發(fā)現(xiàn)兩次打印分別是 1 和 2，也就是說 setState 同步修改了 state，然后每次都觸發(fā)了渲染，所以一共 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 是同步的，那執(zhí)行完就會修改 state，應(yīng)該分別打印 1、2、3，然后觸發(fā)三次 render，加上最開始的一次，一共四次，打印 0、1、2、3。

我們來執(zhí)行一下：

三次打印都是 0，這說明 setState 是異步的。而且三次 setState 只觸發(fā)了一次 render，加上最開始的 render，一共兩次，打印 0、3。

什么鬼，怎么又是異步的了？

而且不止 class 組件的 setState 是這樣，換成 function 組件的 useState 也是一樣的：

比如修改三次 state，只會 render 一次：

而在 setTimeout 里，每次修改 state 都會 render：

是不是有點暈，什么情況下 setState 是同步的，什么情況下是異步的呢？

這要從源碼找答案了，我們來讀一下 setState 的源碼。

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

React 渲染流程

react 通過 jsx 來描述界面，jsx 可以通過 babel 等編譯器編譯成 render function，然后執(zhí)行后產(chǎn)生 vdom：

這個 vdom 也不是直接渲染的，而是會先轉(zhuǎn)化為 fiber，之后再渲染。

因為 vdom 里每個節(jié)點只記錄了子節(jié)點（children），沒有記錄兄弟節(jié)點，所以必須一次性渲染完，不能打斷。

而轉(zhuǎn)成 fiber 的鏈表結(jié)構(gòu)就會記錄父節(jié)點（return）、子節(jié)點（child）、兄弟節(jié)點（sibling），就變成了可打斷的。

這里的 vdom 是 React Element 對象：

轉(zhuǎn)化為 fiber 之后是 FiberNode 的對象：

從 vdom 轉(zhuǎn)換成 fiber 的過程就叫做 reconcile，轉(zhuǎn)換過程中會順便創(chuàng)建對應(yīng)的 dom 元素，然后全部轉(zhuǎn)換完后一次性 commit 到 dom。

這個過程不是一次性的，是通過 scheduler 調(diào)度執(zhí)行的，那也就可以分批次進行，也就是可打斷的含義。

這就是 React 的 fiber 架構(gòu)下的渲染流程。

理論說完了，我們來對應(yīng)到源碼看一下（這里看的是 v17 的源碼）：

react 把 schedule 和 reconcile 叫做 render 階段，這個階段就是把 vdom 轉(zhuǎn)為 fiber。（schedule 只是讓 reconcile 可以分多次執(zhí)行，可以打斷，但做的事情是不變的，所以 schedule 也是 render 階段的一部分）。

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

對應(yīng)到源碼里就是這樣的：

這個 performSyncWorkOnRoot 就是渲染的入口，就像之前所說的，會先執(zhí)行 render 階段，把 vdom 轉(zhuǎn)成 fbier，然后再執(zhí)行 commit，更新到 dom。

render 階段會執(zhí)行一個調(diào)度的 loop：

這個 loop 就是不斷地處理一個個 fiber 的 reconcile：

每個節(jié)點都有 beginWork 和 completeWork 兩個階段，因為要做 vdom 轉(zhuǎn) fiber，而 vdom 是一個樹形結(jié)構(gòu)，需要遞歸處理：

具體不同節(jié)點的 reconcile 邏輯不同：

比如函數(shù)組件會被調(diào)用，拿到 render 出的 vdom 繼續(xù)進行 reconcile：

比如 class 組件會創(chuàng)建實例，調(diào)用 render 方法，拿到 vdom，然后再繼續(xù) renconcileChildren。

總之，vdom 轉(zhuǎn) fiber 是一個遞歸進行的過程。

之后再進行 commit 階段。

整個渲染流程的入口就是 performSyncWorkOnRoot 函數(shù)。

渲染的流程講完了，接下來就是 setState 怎么觸發(fā)渲染的流程了：

setState 的流程

我們知道了渲染的入口就是 performSyncWorkOnRoot 函數(shù)，那 setState 修改完狀態(tài)，觸發(fā)一下這個函數(shù)不就行了？

確實是這樣的。setState 會調(diào)用 dispathAction，創(chuàng)建一個 update 對象放到 fiber 節(jié)點的 updateQueue 上，然后調(diào)度渲染：

調(diào)度更新自然就是調(diào)度上面說的那個 performSyncWorkOnRoot 函數(shù)：

react 會先從觸發(fā) update 的 fiber 往上找到根 fiber 節(jié)點，然后再調(diào)用 performSyncWorkOnRoot 的函數(shù)進行渲染：

這就是 setState 之后觸發(fā)重新渲染的實現(xiàn)。

而 setState 是同步還是異步，也就是在這一段控制的。

我們看到判斷條件里有個 excutionContext，這個是用來標識當前環(huán)境的，比如是批量還是非批量，是否執(zhí)行過 render 階段、commit 階段。

其實在 ReactDOM.render 執(zhí)行的時候會先調(diào)用 unbatchUpdates 函數(shù)：

這個函數(shù)會在 excutionContext 中設(shè)置一個 unbatach 的 flag：

這樣在 update 的時候，就會立刻執(zhí)行 performSyncWorkOnRoot 來渲染。因為首次渲染的時候是馬上就要渲染的，沒必要調(diào)度。

之后走到 commit 階段會設(shè)置一個 commit 的 flag：

然后再次 setState 就不會走到 unbatch 的分支了。

那為什么 setTimeout 里面的 setState 會同步執(zhí)行呢？

因為直接從 setTimeout 執(zhí)行的異步代碼是沒有設(shè)置 excutionContext 的，那就會走到 NoContext 的分支，會立刻渲染。（這里的 flush 最終會調(diào)用 performSyncWorkOnRoot 函數(shù)來渲染）：

有什么辦法能讓 setTimeout 里執(zhí)行的函數(shù)也有 excutionContext 呢？

其實 react17 暴露了 batchUpdates 的 api，用它包裹下，里面的 setState 就會批量執(zhí)行了：

它的源碼其實就是設(shè)置了下 excutionContext：

這樣等 setState 全部執(zhí)行完之后再 flush，調(diào)用 peformSyncWorkOnRoot 渲染，效果就是批量的 setState 了。

其實按理來說 setState 不能叫異步，還是在同一個調(diào)用棧執(zhí)行的，只不過順序不同而已。只能叫批量還是非批量。

在 react17 中是這么處理的，如果是 react18，使用 createRoot 的 api 的話，就不會有這種問題了，就算是 setTimeout 里的代碼也能批量執(zhí)行，

而且為了兼容 react17 這種情況，還做了特殊處理，當沒有開啟并發(fā)模式，也就是還是用 ReactDOM.render 的 api 時，沒有指定 excutionContext 還會立刻渲染：

等 react 18 普及以后，所有的 setState 都是批量的了，就不會再有批量還是非批量的問題。

總結(jié)

雖然我們討論的是 setState 的同步異步，但這個不是 setTimeout、Promise 那種異步，只是指 setState 之后是否 state 馬上變了，是否馬上 render。

我們梳理了下 React 的渲染流程，包括 render 階段、commit 階段，render 階段是從 vdom 轉(zhuǎn) fiber，包含 schedule 和 reconcile，commit 階段是把 fiber 更新到 dom。渲染流程的入口是 performSyncWorkOnRoot 函數(shù)。

setState 會創(chuàng)建 update 對象掛到 fiber 對象上，然后調(diào)度 performSyncWorkOnRoot 重新渲染。

在 react17 中，setState 是批量執(zhí)行的，因為執(zhí)行前會設(shè)置 executionContext。但如果在 setTimeout、事件監(jiān)聽器等函數(shù)里，就不會設(shè)置 executionContext 了，這時候 setState 會同步執(zhí)行。可以在外面包一層 batchUpdates 函數(shù)，手動設(shè)置下 excutionContext 來切換成異步批量執(zhí)行。

在 react18 里面，如果用 createRoot 的 api，就不會有這種問題了。

setState 是同步還是異步這個問題等 react18 普及以后就不會再有了，因為所有的 setState 都是異步批量執(zhí)行了。