2019-6-12 seo達人
如果您想訂閱本博客內容，每天自動發到您的郵箱中， 請點這里
前幾天面試問道 react 的相關知識，對我打擊比較大，感覺對 react 認識非常膚淺，所以在這里重新梳理一下，想想之前沒有仔細思考過的東西。
另外有說的不對的地方還請幫我指正一下，先謝謝各位啦。
目錄索引：
React 有一套合理的運行機制去控制程序在指定的時刻該做什么事，當一個生命周期鉤子被觸發后，緊接著會有下一個鉤子，直到整個生命周期結束。
生命周期代表著每個執行階段，比如組件初始化，更新完成，馬上要卸載等等，React 會在指定的時機執行相關的生命周期鉤子，使我們可以有機在程序運行中會插入自己的邏輯。
我們寫代碼的時候往往會有很多組件以及他們的子組件，各自調用不同的生命周期，這時就要解決誰先誰后的問題，在 react v16 之前是采用了遞歸調用的方式一個一個執行，而在現在 v16 的版本中則采用了與之完全不同的處理（調度）方式，名叫 Fiber，這個東西 facebook 做了有兩年時間，實現非常復雜。
具體 Fiber 它是一個什么東西呢？不要著急，我們先從最基本的生命周期鉤子看起。
首先看一下 React V16.4 后的生命周期概況（圖片來源）
constructor() - 類構造器初始化
static getDerivedStateFromProps() - 組件初始化時主動觸發
render() - 遞歸生成虛擬 DOM
componentDidMount() - 完成首次 DOM 渲染
static getDerivedStateFromProps() - 每次 render() 之前執行
shouldComponentUpdate() - 校驗是否需要執行更新操作
render() - 遞歸生成虛擬 DOM
getSnapshotBeforeUpdate() - 在渲染真實 DOM 之前
componentDidUpdate() - 完成 DOM 渲染
componentWillUnmount() - 組件銷毀之前被直接調用
static getDerivedStateFromProps() 這個鉤子會在每個更新操作之前（即使props沒有改變）執行一次，使用時應該保持謹慎。
componentDidMount() 和 componentDidUpdate() 執行的時機是差不多的，都在 render 之后，只不過前者只在首次渲染后執行，后者首次渲染不會執行
getSnapshotBeforeUpdate() 執行時可以獲得只讀的新 DOM 樹，此函數的返回值為 componentDidUpdate(prevProps, prevState, snapshot) 的第三個參數
關于 Fiber，強烈建議聽一下知乎上程墨Morgan的 live 《深入理解React v16 新功能》，這里潛水員的例子和圖片也是引用于此 live。
我們知道 React 是通過遞歸的方式來渲染組件的，在 V16 版本之前的版本里，當一個狀態發生變更時，react 會從當前組件開始，依次遞歸調用所有的子組件生命周期鉤子，而且這個過程是同步執行的且無法中斷的，一旦有很深很深的組件嵌套，就會造成嚴重的頁面卡頓，影響用戶體驗。
React 在V16版本之前的版本里引入了 Fiber 這樣一個東西，它的英文涵義為纖維，在計算機領域它排在在進程和線程的后面，雖然 React 的 Fiber 和計算機調度里的概念不一樣，但是可以方便對比理解，我們大概可以想象到 Fiber 可能是一個比線程還短的時間片段。
Fiber 把當前需要執行的任務分成一個個微任務，安排優先級，然后依次處理，每過一段時間（非常短，毫秒級）就會暫停當前的任務，查看有沒有優先級較高的任務，然后暫停（也可能會完全放棄）掉之前的執行結果，跳出到下一個微任務。同時 Fiber 還做了一些優化，可以保持住之前運行的結果以到達復用目的。
我們可以把調度當成一個潛水員在海底尋寶，v16 之前是通過組件遞歸的方式進行尋寶，從父組件開始一層一層深入到最里面的子組件，也就是如下圖所示。
而替換成了 Fiber 后，海底變成的狹縫（簡單理解為遞歸變成了遍歷），潛水員會每隔一小段時間浮出水面，看看有沒有其他尋寶任務。注意此時沒有尋到寶藏的話，那么之前潛水的時間就浪費了。就這樣潛水員會一直下潛和冒泡，具體如下圖所示。
從生命周期那張圖片縱向來看，Fiber 將整個生命周期分成了三個階段：
componentWillMount()，componentWillUpdate()，componentWillReceiveProps() 的三個生命周期鉤子被加上了 UNSAFE 標記
簡而言之：以 render() 為界，之前執行的生命周期都有可能會打斷并多次調用，之后的生命周期是不可被打斷的且只會調用一次。所以盡量把副作用的代碼放在只會執行一次的 commit 階段。
除了上面常用的鉤子，React 還提供了如下鉤子：
static getDerivedStateFromError() 在 render 階段執行，通過返回 state 更新組件狀態
componentDidCatch() 在 commit 階段執行，可以放一些有副作用的代碼
理解了生命周期和三個執行階段，就可以比較容易理解組件狀態的更新機制了。
這個方法可以讓我們更新組件的 state 狀態。第一個參數可以是對象，也可以是 updater 函數，如果是函數，則會接受當前的 state 和 props 作為參數。第二個參數為函數，是在 commit 階段后執行，準確的說是在 componentDidUpdate() 后執行。
setState() 的更新過程是異步的（除非綁定在 DOM 事件中或寫在 setTimeout 里），而且會在最后合并所有的更新，如下：
Object.assign( previousState,
{quantity: state.quantity + 1},
{quantity: state.quantity + 1},
...
)
復制代碼之所以設計成這樣，是為了避免在一次生命周期中出現多次的重渲染，影響頁面性能。
如果我們想強制刷新一個組件，可以直接調用該方法，調用時會直接執行 render() 這個函數而跳過 shouldComponentUpdate()。
function wait() { return new Promise(resolve => {
setTimeout(() => {
resolve(); console.log("wait");
}, 0);
});
} //......省略組件創建 async componentDidMount() { await wait(); this.setState({ name: "new name" }); console.log("componentDidMount");
}
componentDidUpdate() { console.log("componentDidUpdate");
}
render() { console.log(this.state); return null } //......省略組件創建 // 輸出結果如下 // wait // {name: "new name"} // componentDidUpdate // componentDidMount // 注意 componentDidUpdate 的輸出位置，一般情況下 // componentDidUpdate 都是在componentDidMount 后面 // 執行的，但是這里因為setState 寫在了 await 后面 // 所以情況相反。 復制代碼了解 react 生命周期和更新機制確實有利于編寫代碼，特別是當代碼量越來越大時，錯用的 setState 或生命周期鉤子都可能埋下越來越多的雷，直到有一天無法維護。。。
我的個人建議如下：
getDerivedStateFromProps() 當成是 UNSAFE_componentWillReceiveProps() 的替代品，因為 getDerivedStateFromProps() 會在每次 render() 之前執行，即使 props 沒有改變
藍藍設計( m.sdgs6788.com )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務。