前言

想起自己(2021年) 8 月份面試時，被面試官們問了好幾個 setState 的問題，現在想想，雖然回答上問題，但是了解得不深刻。我知道 setState 被設計成“異步”是為了性能，但是涉及到源碼解讀我就歇菜了;我知道如何讓它同步，但是遇到真實的代碼情況時，卻不知道如何下手。說到底，當時是準備了面經把這些概念記下來，而沒有真正理解它

在認識 setState 前，我們問幾個常見問題

• setState 是同步還是異步?
• 如果是異步，怎么讓它同步?
• 為什么要這樣設計?

基本概念和使用

React 的理念之一是 UI=f(data)，修改 data 即驅動 UI 變化，那么怎么修改呢?React 提供了一個 API ——setState(類組件的修改方法)

官網介紹：

• setState() 將對組件 state 的更新排入隊列，并通知 React 需要使用更新后的 state 重新渲染此組件及其子組件。這是用于更新用戶界面以響應事件處理器和處理服務器數據的主要方式
• 為了更好的感知性能，React 會延遲調用它，然后通過一次傳遞更新多個組件。React 并不會保證 state 的變更會立即生效
• setState() 并不總是立即更新組件。它會批量推遲更新。這使得在調用 setState() 后立即讀取 this.state 成為了隱患。為了消除隱患，請使用 componentDidUpdate 或者 setState 的回調函數(setState(updater, callback))，這兩種方式都可以保證在應用更新后觸發
• 除非 shouldComponentUpdate() 返回 false，否則 setState() 將始終執行重新渲染操作。如果可變對象被使用，且無法在 shouldComponentUpdate() 中實現條件渲染，那么僅在新舊狀態不一致調用 setState()可以避免不必要的重新渲染

使用方法

setState(updater, [callback])

參數一為帶有形式參數的 updater 函數：

(state, props) => stateChange

// 例如
// this.setState((state, props) => {
//   return {counter: state.counter + props.step};
// });

setState 的第一個參數除了接受函數外，還可以接受對象類型：

setState(stateChange[, callback])
// 例如：this.setState({count: 2})

setState 的第二個參數為可選的回調函數，它將在 setState 完成合并重新渲染組件后執行。通常，我們建議使用 componentDidUpdate 來代替此方法

setState(stateChange[, callback])
// 例如: this.setState({count: 2}, () => {console.log(this.state.count)}) 

與 setState 回調相比，使用 componentDidUpdate 有什么優勢?

stackoverflow 有人問過，也有人回答過：

• 一致的邏輯
• 批量更新
• 什么時候 setState 會比較好? 當外部代碼需要等待狀態更新時，如 Promise

setState 的特性——批處理

如果在同一周期內對多個 setState 進行處理，例如，在同一周期內多次設置商品數據，相當于：

this.setState({count: state.count + 1});
this.setState({count: state.count + 1});
this.setState({count: state.count + 1});
// === 
Object.assign(
  count,
  {quantity: state.quantity + 1},
  {quantity: state.quantity + 1},
  ...
)

后調的 setState 將覆蓋同一周期內先調用 setState 的值

• setState(stateChange[, callback])
• setState((state, props) => stateChange[, callback])

setState 必引發更新過程，但不一定會引發 render 被執行，因為 shouldCompomentUpdate 可以返回 false

批處理引發的問題

問題1：連續使用 setState，為什么不能實時改變

state.count = 0;
this.setState({count: state.count + 1}); 
this.setState({count: state.count + 1}); 
this.setState({count: state.count + 1}); 
// state.count === 1，不是 3

因為 this.setState 方法為會進行批處理，后調的 setState 會覆蓋統一周期內先調用的 setState 的值，如下圖所示：

state.count = 0;
this.setState({count: state.count + 2}); 
this.setState({count: state.count + 3}); 
this.setState({count: state.count + 4}); 
// state.count === 4

問題2：為什么要 setState，而不是直接 this.state.xx = oo?

因為 setState 做的事情不僅僅只是修改了 this.state 的值，另外最重要的是它會觸發 React 的更新機制，會進行diff，然后將 patch 部分更新到真實 dom 里

如果你直接 this.state.xx = oo 的話，state 的值確實會改，但是它不會驅動 React 重渲染。setState 能幫助我們更新視圖，引發 shouldComponentUpdate、render 等一系列函數的調用。至于批處理，React 會將 setState 的效果放入隊列中，在事件結束之后產生一次重新渲染，為的就是把 Virtual DOM 和 DOM 樹操作降到最小，用于提高性能

當調用 setState 后，React 的 生命周期函數 會依次順序執行

• static getDerivedStateFromProps
• shouldComponentUpdate
• render
• getSnapshotBeforeUpdate
• componentDidUpdate

問題3：那為什么會出現異步的情況呢?(為什么這么設計?)

因為性能優化。假如每次 setState 都要更新數據，更新過程就要走五個生命周期，走完一輪生命周期再拿 render 函數的結果去做 diff 對比和更新真實 DOM，會很耗時間。所以將每次調用都放一起做一次性處理，能降低對 DOM 的操作，提高應用性能

問題4：那如何在表現出異步的函數里可以準確拿到更新后的 state 呢?

通過第二個參數 setState(partialState, callback) 中的 callback 拿到更新后的結果

onHandleClick() {
    this.setState(
        {
            count: this.state.count + 1,
        },
        () => {
            console.log("點擊之后的回調", this.state.count); // 最新值
        }
    );
}

或者可以直接給 state 傳遞函數來表現出同步的情況

this.setState(state => {
 console.log("函數模式", state.count);
 return { count: state.count + 1 };
});

執行原理

首先先了解三種渲染模式

• legacy 模式：ReactDOM.render(, rootNode) 。這是當前 React app 使用的方式。當前沒有計劃刪除本模式，但是這個模式可能不支持新功能
• blocking 模式：
• ReactDOM.createBlockingRoot(rootNode).render() 。目前正在實驗中，作為遷移到 concurrent 模式的第一個步驟
• concurrent 模式 ：ReactDOM.createRoot(rootNode).render()。目前在實驗中，未來穩定之后，打算作為 React 的模式開發模式。這個模式開啟了所有的新功能 擁有不同的優先級，更新的過程可以被打斷

在 legacy 模式下，在 React 的 setState 函數實現中，會根據一個變量 isBatchingUpdates 判斷是直接更新 this.state 還是放到隊列中回頭再說，而 isBatchingUpdates 默認是 false，也就表示 setState 會同步更新 this.state，但是，有一個函數 batchedUpdates，這個函數會把 isBatchingUpdates 修改為 true，而當 React 在調用事件處理函數之前就會調用這個 batchedUpdates，造成的后果，就是由 React 控制的事件處理過程 setState 不會同步更新 this.state

像 addEventListener 綁定的原生事件、setTimeout/setInterval 會走同步，除此之外，也就是 React 控制的事件處理 setState 會異步

而 concurrent 模式都是異步，這也是未來 React 18 的默認模式

總結

首先，我們總結下關鍵知識點

• setState 不會立即改變 React 組件中 state 的值
• setState 通過引發一次組件的更新過程來引發重新繪制
• 多次 setState 函數調用產生的效果會合并(批處理)

其次，回答一下文章開頭的問題(第二第三問題在文中已經回答)

setState 是同步還是異步?

• 代碼同步，渲染看模式 legacy模式，非原生事件、setTimeout/setInterval 的情況下為異步;addEventListener 。 綁定原生事件、setTimeout/setInterval 時會同步concurrent 模式：異步