號外號外!走過路過千萬不要錯過!javascript
截止目前爲止 React 已經發布了 v16.12.0
版本, React 生命週期也是平常開發低頭不見,擡頭見的狗子,惋惜狗子它變了。java
v16.3 版本以前, React 中的更新操做是同步的,這可能會致使性能問題。react
舉個例子,假若有一個龐大的模塊裏面嵌套超級多的組件,一旦最頂部的 render 方法執行了,而後依次執行組件的 render 方法,直到最底層組件。這個過程會致使主線程卡主。git
官方爲了解決這個問題,所以引入了 React Fiber,其解決思路是分片執行,一個更新過程被分爲兩個階段(Phase):第一個階段 Reconciliation Phase 和第二階段 Commit Phase。github
在第一階段 Reconciliation Phase,React Fiber 會找出須要更新哪些 DOM,這個階段是能夠被打斷的;可是到了第二階段 Commit Phase,那就一氣呵成把 DOM 更新完,毫不會被打斷。算法
而這兩個階段也對應到不一樣的生命週期:dom
第一階段異步
第二階段函數
能夠看看這個例子:Fiber vs Stack Demopost
之前:
如今( v16.3 ):
對比上下兩張圖,發現 React 廢棄瞭如下方法:
這裏須要說明一下:爲了作到版本版本兼容 增長 UNSAFE_componentWillMount
,UNSAFE_componentWillReceiveProps
和UNSAFE_componentWillUpdate
方法,新舊方法都能使用,但使用舊方法,開發模式下會有紅色警告,在 React v17 更新時會完全廢棄。
新增了方法以下:
下面從三個階段(掛載、更新、卸載)梳理下生命週期方法。
執行的生命週期方法,若是須要作一些初始化操做,好比初始化 state, 反正則無需爲 React 組件實現構造函數。
當組件實例化的時候,這個方法替代了 componentWillMount(),而當接收到新的 props 時,該方法替代了 componentWillReceiveProps() 和 componentWillUpdate()。
static getDerivedStateFromProps(nextProps, prevState)
複製代碼
其中 v16.3 版本中 re-rendering 以後此方法不會被調用,而 v16.4 版本中 re-rendering 以後都會調用此方法,這意味及時的 props 未發生改變,一旦父組件發生 re-rendering 那麼子組件的該方法依然會被調用。
部分同窗平常會把數據請求放在該方法內,以便於快速獲取數據並展示,個人理解再怎麼快,也快不過首次 render,而且 React Fiber 執行機制的緣由,會致使該方法被執行屢次,這也意味着接口被請求屢次。所以該方法在 v17 版本之後將被完全廢棄。
在組件掛載完成後調用,且全局只調用一次。能夠在這裏使用 refs,獲取真實 dom 元素。該鉤子內也能夠發起異步請求,並在異步請求中能夠進行 setState。
被 getDerivedStateFromProps 方法取代。
每次調用 setState 後都會調用 shouldComponentUpdate 判斷是否須要從新渲染組件。默認返回 true,須要從新 render。返回 false 則不觸發渲染。在比較複雜的應用裏,有一些數據的改變並不影響界面展現,能夠在這裏作判斷,優化渲染效率。
依舊是 React Fiber 執行機制的緣由,在該方法記錄 DOM 狀態就不在準確了。
觸發該方法的實際,是在更新 DOM 以前的一瞬間,比 componentWillUpdate 記錄的 DOM 狀態更爲精確。
除了首次 render 以後調用 componentDidMount,其它 render 結束以後都是調用 componentDidUpdate。
組件被卸載的時候調用。通常在 componentDidMount 裏面註冊的事件須要在這裏刪除。
因爲 React 同步更新組件的緣由,會引發性能問題,形成主線程卡死,所以引入 React Fiber 對核心算法的一次從新實現。 緊接着發現, React Fiber 會讓部分生命週期方法行屢次,而廢除這部分方法,引入新方法。
參考文章: