国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

React-生命周期雜記

KoreyLee / 827人閱讀

摘要：前言自從發(fā)布之后，更新速度日新月異，而生命周期也隨之改變，雖然原有的一些生命周期函數(shù)面臨廢棄，但理解其背后更新的機制也是一種學(xué)習(xí)在這里根據(jù)官方文檔以及社區(qū)上其他優(yōu)秀的文章進行一個對于生命周期的總結(jié)，大致上分為以下三個模塊新老生命周期的區(qū)別為

前言

自從React發(fā)布Fiber之后，更新速度日新月異，而生命周期也隨之改變，雖然原有的一些生命周期函數(shù)面臨廢棄，但理解其背后更新的機制也是一種學(xué)習(xí)

在這里根據(jù)官方文檔以及社區(qū)上其他優(yōu)秀的文章進行一個對于生命周期的總結(jié)，大致上分為以下三個模塊

新老生命周期的區(qū)別

為什么數(shù)據(jù)獲取要在componentDidMount中進行

為什么要改變生命周期

新老生命周期的區(qū)別

新的生命周期增加了static getDerivedStateFromProps()以及getSnapshotBeforeUpdate()，廢棄了原有的componentWillMount()、componentWillUpdate()以及componentWillReceiveProps()，
分別如以下圖

原生命周期：

新生命周期（圖引用自React v16.3之后的組件生命周期函數(shù)）：

為什么數(shù)據(jù)獲取要在componentDidMount中進行

作者一開始也喜歡在React的willMount函數(shù)中進行異步獲取數(shù)據(jù)（認(rèn)為這可以減少白屏的時間），后來發(fā)現(xiàn)其實應(yīng)該在didMount中進行。

首先，分析一下兩者請求數(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é)省時間（render函數(shù)和didMount函數(shù)的執(zhí)行時間），但是為什么我們還要在didMount中獲取數(shù)據(jù)

如果使用服務(wù)端渲染的話，willMount會在服務(wù)端和客戶端各自執(zhí)行一次，這會導(dǎo)致請求兩次（接受不了~），而didMount只會在客戶端進行

在Fiber之后， 由于任務(wù)可中斷，willMount可能會被執(zhí)行多次

willMount會被廢棄，目前被標(biāo)記為不安全

節(jié)省的時間非常少，跟其他的延遲情況相比，這個優(yōu)化可以使用九牛一毛的形容（為了這么一點時間而一直不跟進技術(shù)的發(fā)展，得不償失），并且render函數(shù)是肯定比異步數(shù)據(jù)到達(dá)先執(zhí)行，白屏?xí)r間并不能減少

關(guān)于第一點，如果你想在服務(wù)端渲染時先完成數(shù)據(jù)的展示再一次性給用戶，官方的推薦做法是用constructor代替willMount

為什么要改變生命周期

從上面的生命周期的圖中可以看出，被廢棄的三個函數(shù)都是在render之前，因為fiber的出現(xiàn)，很可能因為高優(yōu)先級任務(wù)的出現(xiàn)而打斷現(xiàn)有任務(wù)導(dǎo)致它們會被執(zhí)行多次

另外的一個原因則是，React想約束使用者，好的框架能夠讓人不得已寫出容易維護和擴展的代碼，這一點又是從何談起，我們可以從新增加以及即將廢棄的生命周期分析入手

componentWillMoun

首先這個函數(shù)的功能完全可以使用componentDidMount和constructor來代替，異步獲取的數(shù)據(jù)的情況上面已經(jīng)說明了，而如果拋去異步獲取數(shù)據(jù)，其余的即是初始化而已，這些功能都可以在constructor中執(zhí)行，除此之外，如果我們在willMount中訂閱事件，但在服務(wù)端這并不會執(zhí)行willUnMount事件，也就是說服務(wù)端會導(dǎo)致內(nèi)存泄漏

所以componentWillMount完全可以不使用，但使用者有時候難免因為各種各樣的情況（如作者犯渾）在componentWillMount中做一些操作，那么React為了約束開發(fā)者，干脆就拋掉了這個API

componentWillReceiveProps 
在老版本的 React 中，如果組件自身的某個 state 跟其 props 密切相關(guān)的話，一直都沒有一種很優(yōu)雅的處理方式去更新 state，而是需要在 componentWillReceiveProps 中判斷前后兩個 props 是否相同，如果不同再將新的 props 更新到相應(yīng)的 state 上去。這樣做一來會破壞 state 數(shù)據(jù)的單一數(shù)據(jù)源，導(dǎo)致組件狀態(tài)變得不可預(yù)測，另一方面也會增加組件的重繪次數(shù)。類似的業(yè)務(wù)需求也有很多，如一個可以橫向滑動的列表，當(dāng)前高亮的 Tab 顯然隸屬于列表自身的狀態(tài)，但很多情況下，業(yè)務(wù)需求會要求從外部跳轉(zhuǎn)至列表時，根據(jù)傳入的某個值，直接定位到某個 Tab。 本段引用自React v16.3 版本新生命周期函數(shù)淺析及升級方案

為了解決這些問題，React引入了第一個新的生命周期

static getDerivedStateFromProps

可以先看一下兩者在使用上的區(qū)別：

原有的代碼

新的代碼

這樣看似乎沒有什么改變，特別是當(dāng)我們把this,tabChange也放在didUpdate中執(zhí)行時（正確做法），完全沒有不同，但這也是我們一開始想說的，React通過API來約束開發(fā)者寫出更好的代碼，而新的使用方法有以下的優(yōu)點

getDSFP是靜態(tài)方法，在這里不能使用this，也就是一個純函數(shù)，開發(fā)者不能寫出副作用的代碼

開發(fā)者只能通過prevState而不是prevProps來做對比，保證了state和props之間的簡單關(guān)系以及不需要處理第一次渲染時prevProps為空的情況

基于第一點，將狀態(tài)變化（setState）和昂貴操作（tabChange）區(qū)分開，更加便于 render 和 commit 階段操作或者說優(yōu)化。

componentWillUpdate 
與 componentWillReceiveProps 類似，許多開發(fā)者也會在 componentWillUpdate 中根據(jù) props 的變化去觸發(fā)一些回調(diào)。但不論是 componentWillReceiveProps 還是 componentWillUpdate，都有可能在一次更新中被調(diào)用多次，也就是說寫在這里的回調(diào)函數(shù)也有可能會被調(diào)用多次，這顯然是不可取的。與 componentDidMount 類似，componentDidUpdate 也不存在這樣的問題，一次更新中 componentDidUpdate 只會被調(diào)用一次，所以將原先寫在 componentWillUpdate 中的回調(diào)遷移至 componentDidUpdate 就可以解決這個問題。本段引用自React v16.3 版本新生命周期函數(shù)淺析及升級方案

另外一種情況則是我們需要獲取DOM元素狀態(tài)，但是由于在fiber中，render可打斷，可能在willMount中獲取到的元素狀態(tài)很可能與實際需要的不同，這個通常可以使用第二個新增的生命函數(shù)的解決

getSnapshotBeforeUpdate 
getSnapshotBeforeUpdate(prevProps, prevState) // 返回的值作為componentDidUpdate的第三個參數(shù)

與willMount不同的是， getSnapshotBeforeUpdate會在最終確定的render執(zhí)行之前執(zhí)行，也就是能保證其獲取到的元素狀態(tài)與didUpdate中獲取到的元素狀態(tài)相同，這里官方提供了一段參考代碼：

總結(jié)

隨著React Fiber的落地，許多功能都將開始改變，但本質(zhì)上是換湯不換藥，很多時候都是React為了開發(fā)者寫出更好的代碼而做的改變，當(dāng)然這也是React的厲害之處，通過框架來約束開發(fā)者！

文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/101592.html

相關(guān)文章

  • React-setState雜記

    摘要：簡單的舉下例子如等生命周期以及的事件即為異步更新，這里不顯示具體代碼。因為只有當(dāng)父組件后才傳給子組件，那么如果要變成同步的，就需要放棄。 前言 在看React的官方文檔的時候， 發(fā)現(xiàn)了這么一句話，State Updates May Be Asynchronous，于是查詢了一波資料， 最后歸納成以下3個問題 setState為什么要異步更新，它是怎么做的？ setState什么時候會...

    yuxue 評論0 收藏0

  • React-Router 雜記

    摘要：三種的區(qū)別即對應(yīng)中的值，如，服務(wù)器對任務(wù)都返回同一個，具體的路徑由瀏覽器區(qū)分，因為瀏覽器不會發(fā)送后面的值給服務(wù)器。如果是即變成這樣，，所以要對服務(wù)器配置不同的返回不同的資源。就是沒有的情況，比如。 三種Router的區(qū)別 1. HashRouter: 即對應(yīng)url中的hash值，如xx.com/#/a、xx.com/#/a/b， 服務(wù)器對任務(wù)url都返回同一個url，具體的路徑由瀏覽器...

    keelii 評論0 收藏0

  • React-flux雜記

    摘要：簡介是一種搭建客戶端的應(yīng)用架構(gòu)，更像是一種模式而不是一個框架。 簡介 Flux是一種搭建WEB客戶端的應(yīng)用架構(gòu)，更像是一種模式而不是一個框架。 特點 單向數(shù)據(jù)流 showImg(https://segmentfault.com/img/remote/1460000018128072?w=1300&h=708); 與MVC的比較 1.傳統(tǒng)的MVC如下所示（是一個雙向數(shù)...

    王巖威 評論0 收藏0

  • React-事件機制雜記

    摘要：前提最近通過閱讀官方文檔的事件模塊，有了一些思考和收獲，在這里記錄一下調(diào)用方法時需要手動綁定先從一段官方代碼看起代碼中的注釋提到了一句話的綁定是必須的，其實這一塊是比較容易理解的，因為這并不是的一個特殊點，而是這門語言的特性。 前提 最近通過閱讀React官方文檔的事件模塊，有了一些思考和收獲，在這里記錄一下~ 調(diào)用方法時需要手動綁定this 先從一段官方代碼看起： showImg(...

    zhangyucha0 評論0 收藏0

  • Webpack系列-第一篇基礎(chǔ)雜記

    摘要：系列文章系列第一篇基礎(chǔ)雜記系列第二篇插件機制雜記系列第三篇流程雜記前言公司的前端項目基本都是用來做工程化的，而雖然只是一個工具，但內(nèi)部涉及到非常多的知識，之前一直靠來解決問題，之知其然不知其所以然，希望這次能整理一下相關(guān)的知識點。 系列文章 Webpack系列-第一篇基礎(chǔ)雜記 Webpack系列-第二篇插件機制雜記 Webpack系列-第三篇流程雜記 前言 公司的前端項目基本都是用...

    Batkid 評論0 收藏0

發(fā)表評論

0條評論

最新活動
閱讀需要支付1元查看
<