資訊專欄INFORMATION COLUMN
摘要：前言自從發(fā)布之后，更新速度日新月異，而生命周期也隨之改變，雖然原有的一些生命周期函數(shù)面臨廢棄，但理解其背后更新的機(jī)制也是一種學(xué)習(xí)在這里根據(jù)官方文檔以及社區(qū)上其他優(yōu)秀的文章進(jìn)行一個(gè)對(duì)于生命周期的總結(jié)，大致上分為以下三個(gè)模塊新老生命周期的區(qū)別為
前言
自從React發(fā)布Fiber之后，更新速度日新月異，而生命周期也隨之改變，雖然原有的一些生命周期函數(shù)面臨廢棄，但理解其背后更新的機(jī)制也是一種學(xué)習(xí)
在這里根據(jù)官方文檔以及社區(qū)上其他優(yōu)秀的文章進(jìn)行一個(gè)對(duì)于生命周期的總結(jié)，大致上分為以下三個(gè)模塊
新老生命周期的區(qū)別
為什么數(shù)據(jù)獲取要在componentDidMount中進(jìn)行
為什么要改變生命周期
新老生命周期的區(qū)別新的生命周期增加了static getDerivedStateFromProps()以及getSnapshotBeforeUpdate()，廢棄了原有的componentWillMount()、componentWillUpdate()以及componentWillReceiveProps()，
分別如以下圖
原生命周期：
新生命周期（圖引用自React v16.3之后的組件生命周期函數(shù)）：
為什么數(shù)據(jù)獲取要在componentDidMount中進(jìn)行作者一開始也喜歡在React的willMount函數(shù)中進(jìn)行異步獲取數(shù)據(jù)（認(rèn)為這可以減少白屏的時(shí)間），后來(lái)發(fā)現(xiàn)其實(shí)應(yīng)該在didMount中進(jìn)行。
首先，分析一下兩者請(qǐng)求數(shù)據(jù)的區(qū)別：
componentWillMount獲取數(shù)據(jù)：
執(zhí)行willMount函數(shù)，等待數(shù)據(jù)返回
執(zhí)行render函數(shù)
執(zhí)行didMount函數(shù)
數(shù)據(jù)返回， 執(zhí)行render
didMount獲取數(shù)據(jù)：
執(zhí)行willMount函數(shù)
執(zhí)行render函數(shù)
執(zhí)行didMount函數(shù)， 等待數(shù)據(jù)返回
數(shù)據(jù)返回， 執(zhí)行render
很明顯，在willMount中獲取數(shù)據(jù)，可以節(jié)省時(shí)間（render函數(shù)和didMount函數(shù)的執(zhí)行時(shí)間），但是為什么我們還要在didMount中獲取數(shù)據(jù)
如果使用服務(wù)端渲染的話，willMount會(huì)在服務(wù)端和客戶端各自執(zhí)行一次，這會(huì)導(dǎo)致請(qǐng)求兩次（接受不了~），而didMount只會(huì)在客戶端進(jìn)行
在Fiber之后， 由于任務(wù)可中斷，willMount可能會(huì)被執(zhí)行多次
willMount會(huì)被廢棄，目前被標(biāo)記為不安全
節(jié)省的時(shí)間非常少，跟其他的延遲情況相比，這個(gè)優(yōu)化可以使用九牛一毛的形容（為了這么一點(diǎn)時(shí)間而一直不跟進(jìn)技術(shù)的發(fā)展，得不償失），并且render函數(shù)是肯定比異步數(shù)據(jù)到達(dá)先執(zhí)行，白屏?xí)r間并不能減少
關(guān)于第一點(diǎn)，如果你想在服務(wù)端渲染時(shí)先完成數(shù)據(jù)的展示再一次性給用戶，官方的推薦做法是用constructor代替willMount
為什么要改變生命周期從上面的生命周期的圖中可以看出，被廢棄的三個(gè)函數(shù)都是在render之前，因?yàn)閒iber的出現(xiàn)，很可能因?yàn)?strong>高優(yōu)先級(jí)任務(wù)的出現(xiàn)而打斷現(xiàn)有任務(wù)導(dǎo)致它們會(huì)被執(zhí)行多次
另外的一個(gè)原因則是，React想約束使用者，好的框架能夠讓人不得已寫出容易維護(hù)和擴(kuò)展的代碼，這一點(diǎn)又是從何談起，我們可以從新增加以及即將廢棄的生命周期分析入手
componentWillMoun首先這個(gè)函數(shù)的功能完全可以使用componentDidMount和constructor來(lái)代替，異步獲取的數(shù)據(jù)的情況上面已經(jīng)說明了，而如果拋去異步獲取數(shù)據(jù)，其余的即是初始化而已，這些功能都可以在constructor中執(zhí)行，除此之外，如果我們?cè)趙illMount中訂閱事件，但在服務(wù)端這并不會(huì)執(zhí)行willUnMount事件，也就是說服務(wù)端會(huì)導(dǎo)致內(nèi)存泄漏
所以componentWillMount完全可以不使用，但使用者有時(shí)候難免因?yàn)楦鞣N各樣的情況（如作者犯渾）在componentWillMount中做一些操作，那么React為了約束開發(fā)者，干脆就拋掉了這個(gè)API
componentWillReceiveProps在老版本的 React 中，如果組件自身的某個(gè) state 跟其 props 密切相關(guān)的話，一直都沒有一種很優(yōu)雅的處理方式去更新 state，而是需要在 componentWillReceiveProps 中判斷前后兩個(gè) props 是否相同，如果不同再將新的 props 更新到相應(yīng)的 state 上去。這樣做一來(lái)會(huì)破壞 state 數(shù)據(jù)的單一數(shù)據(jù)源，導(dǎo)致組件狀態(tài)變得不可預(yù)測(cè)，另一方面也會(huì)增加組件的重繪次數(shù)。類似的業(yè)務(wù)需求也有很多，如一個(gè)可以橫向滑動(dòng)的列表，當(dāng)前高亮的 Tab 顯然隸屬于列表自身的狀態(tài)，但很多情況下，業(yè)務(wù)需求會(huì)要求從外部跳轉(zhuǎn)至列表時(shí)，根據(jù)傳入的某個(gè)值，直接定位到某個(gè) Tab。 本段引用自React v16.3 版本新生命周期函數(shù)淺析及升級(jí)方案
為了解決這些問題，React引入了第一個(gè)新的生命周期
static getDerivedStateFromProps可以先看一下兩者在使用上的區(qū)別：
原有的代碼
新的代碼
這樣看似乎沒有什么改變，特別是當(dāng)我們把this,tabChange也放在didUpdate中執(zhí)行時(shí)（正確做法），完全沒有不同，但這也是我們一開始想說的，React通過API來(lái)約束開發(fā)者寫出更好的代碼，而新的使用方法有以下的優(yōu)點(diǎn)
getDSFP是靜態(tài)方法，在這里不能使用this，也就是一個(gè)純函數(shù)，開發(fā)者不能寫出副作用的代碼
開發(fā)者只能通過prevState而不是prevProps來(lái)做對(duì)比，保證了state和props之間的簡(jiǎn)單關(guān)系以及不需要處理第一次渲染時(shí)prevProps為空的情況
基于第一點(diǎn)，將狀態(tài)變化（setState）和昂貴操作（tabChange）區(qū)分開，更加便于 render 和 commit 階段操作或者說優(yōu)化。
componentWillUpdate與 componentWillReceiveProps 類似，許多開發(fā)者也會(huì)在 componentWillUpdate 中根據(jù) props 的變化去觸發(fā)一些回調(diào)。但不論是 componentWillReceiveProps 還是 componentWillUpdate，都有可能在一次更新中被調(diào)用多次，也就是說寫在這里的回調(diào)函數(shù)也有可能會(huì)被調(diào)用多次，這顯然是不可取的。與 componentDidMount 類似，componentDidUpdate 也不存在這樣的問題，一次更新中 componentDidUpdate 只會(huì)被調(diào)用一次，所以將原先寫在 componentWillUpdate 中的回調(diào)遷移至 componentDidUpdate 就可以解決這個(gè)問題。本段引用自React v16.3 版本新生命周期函數(shù)淺析及升級(jí)方案
另外一種情況則是我們需要獲取DOM元素狀態(tài)，但是由于在fiber中，render可打斷，可能在willMount中獲取到的元素狀態(tài)很可能與實(shí)際需要的不同，這個(gè)通?？梢允褂玫诙€(gè)新增的生命函數(shù)的解決
getSnapshotBeforeUpdategetSnapshotBeforeUpdate(prevProps, prevState) // 返回的值作為componentDidUpdate的第三個(gè)參數(shù)
與willMount不同的是， getSnapshotBeforeUpdate會(huì)在最終確定的render執(zhí)行之前執(zhí)行，也就是能保證其獲取到的元素狀態(tài)與didUpdate中獲取到的元素狀態(tài)相同，這里官方提供了一段參考代碼：
隨著React Fiber的落地，許多功能都將開始改變，但本質(zhì)上是換湯不換藥，很多時(shí)候都是React為了開發(fā)者寫出更好的代碼而做的改變，當(dāng)然這也是React的厲害之處，通過框架來(lái)約束開發(fā)者！
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://www.ezyhdfw.cn/yun/101592.html
摘要：簡(jiǎn)單的舉下例子如等生命周期以及的事件即為異步更新，這里不顯示具體代碼。因?yàn)橹挥挟?dāng)父組件后才傳給子組件，那么如果要變成同步的，就需要放棄。 前言 在看React的官方文檔的時(shí)候， 發(fā)現(xiàn)了這么一句話，State Updates May Be Asynchronous，于是查詢了一波資料， 最后歸納成以下3個(gè)問題 setState為什么要異步更新，它是怎么做的？ setState什么時(shí)候會(huì)...
摘要：三種的區(qū)別即對(duì)應(yīng)中的值，如，服務(wù)器對(duì)任務(wù)都返回同一個(gè)，具體的路徑由瀏覽器區(qū)分，因?yàn)闉g覽器不會(huì)發(fā)送后面的值給服務(wù)器。如果是即變成這樣，，所以要對(duì)服務(wù)器配置不同的返回不同的資源。就是沒有的情況，比如。 三種Router的區(qū)別 1. HashRouter: 即對(duì)應(yīng)url中的hash值，如xx.com/#/a、xx.com/#/a/b， 服務(wù)器對(duì)任務(wù)url都返回同一個(gè)url，具體的路徑由瀏覽器...
摘要：簡(jiǎn)介是一種搭建客戶端的應(yīng)用架構(gòu)，更像是一種模式而不是一個(gè)框架。 簡(jiǎn)介 Flux是一種搭建WEB客戶端的應(yīng)用架構(gòu)，更像是一種模式而不是一個(gè)框架。 特點(diǎn) 單向數(shù)據(jù)流 showImg(https://segmentfault.com/img/remote/1460000018128072?w=1300&h=708); 與MVC的比較 1.傳統(tǒng)的MVC如下所示（是一個(gè)雙向數(shù)...
摘要：前提最近通過閱讀官方文檔的事件模塊，有了一些思考和收獲，在這里記錄一下調(diào)用方法時(shí)需要手動(dòng)綁定先從一段官方代碼看起代碼中的注釋提到了一句話的綁定是必須的，其實(shí)這一塊是比較容易理解的，因?yàn)檫@并不是的一個(gè)特殊點(diǎn)，而是這門語(yǔ)言的特性。 前提 最近通過閱讀React官方文檔的事件模塊，有了一些思考和收獲，在這里記錄一下~ 調(diào)用方法時(shí)需要手動(dòng)綁定this 先從一段官方代碼看起： showImg(...
摘要：系列文章系列第一篇基礎(chǔ)雜記系列第二篇插件機(jī)制雜記系列第三篇流程雜記前言公司的前端項(xiàng)目基本都是用來(lái)做工程化的，而雖然只是一個(gè)工具，但內(nèi)部涉及到非常多的知識(shí)，之前一直靠來(lái)解決問題，之知其然不知其所以然，希望這次能整理一下相關(guān)的知識(shí)點(diǎn)。 系列文章 Webpack系列-第一篇基礎(chǔ)雜記 Webpack系列-第二篇插件機(jī)制雜記 Webpack系列-第三篇流程雜記 前言 公司的前端項(xiàng)目基本都是用...
閱讀 2811·2021-11-22 15:22
閱讀 1727·2021-11-22 14:56
閱讀 3700·2021-09-22 15:12
閱讀 2474·2021-09-02 15:41
閱讀 2216·2021-08-27 16:26
閱讀 1184·2019-08-30 15:55
閱讀 2200·2019-08-29 17:30
閱讀 737·2019-08-29 16:26
