欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

想用好React的你必須要知道的一些事情

 更新時間:2017年07月24日 10:51:38   作者:xuchaobei  
現(xiàn)在最熱門的前端框架,毫無疑問是 React 。下面這篇文章主要給大家分享了關(guān)于想用好React的你必須要知道的一些事情,文中介紹的非常詳細,對大家具有一定參考學習價值,需要的朋友們下面來一起看看吧。

前言

React 是 Facebook 里一群牛 X 的碼農(nóng)折騰出的牛X的框架。 實現(xiàn)了一個虛擬 DOM,用 DOM 的方式將需要的組件秒加,用不著的秒刪。本文主要給大家介紹了關(guān)于想用好React的你必須要知道的一些事情,下面話不多說,來一起看看詳細的介紹:

一、容器性組件(container component)和展示性組件(presentational component)

使用React編寫組件時,我們需要有意識地將組件劃分為容器性組件(container component)和展示性組件(presentational component),這樣有助于我們在編寫組件時,更加明確這個組件應(yīng)該負責哪些事情。

容器性組件,負責業(yè)務(wù)流程邏輯的處理,如發(fā)送網(wǎng)絡(luò)請求,處理請求數(shù)據(jù),將處理過的數(shù)據(jù)傳遞給子組件的Props使用。同時,容器性組件提供源數(shù)據(jù)的方法,以Props方式傳遞給子組件,當子組件的狀態(tài)變更引起源數(shù)據(jù)的變化時,子組件通過調(diào)用容器性組件提供的方法同步這些變化。

展示性組件,負責組件的外表,也就是組件如何渲染,具有很強的內(nèi)聚性。展示性組件不關(guān)心渲染時使用的組件屬性(Props)是如何獲取到的,它只要知道有了這些Props后,組件應(yīng)該如何渲染就足夠了。屬性如何獲取,是容器性組件負責的事情。當展示性組件狀態(tài)的變化需要同步到源數(shù)據(jù)時,需要調(diào)用容器性組件中的方法,這個方法一般也是通過Props傳遞給展示性組件。

例如,一個Todo項目,有一個Todo組件和一個TodoList組件,Todo組件是一個容器性組件,負責從服務(wù)器端獲取待辦事項列表,獲取到待辦事項列表后傳遞給TodoList顯示。當在TodoList中新建一項待辦事項后,需要通過TodoList 的 Props,調(diào)用Todo組件中保存待辦項目的方法,將新建的待辦項目同步到服務(wù)器端。

容器性組件和展示性組件可以相互嵌套,一個容器性組件可以包含多個展示性組件和其他的容器性組件;一個展示性組將也可以包含容器性組件和其他的展示性組件。這樣的分工,可以使與組件渲染無直接關(guān)系的邏輯由容器性組件集中負責,展示性組件只關(guān)注組件的渲染邏輯,從而使展示性組件更容易被復用。對于非常簡單的頁面,一般只要一個容器性組件就足夠了;但對于負責頁面,則需要多個容器性組件,否則所有的業(yè)務(wù)邏輯都在一個容器性組件中處理的話,會導致這個組件非常復雜,同時這個組件獲取到的源數(shù)據(jù),可能需要經(jīng)過很多層的組件Props的傳遞,才能到達最終使用的展示性組件。

二、Props、State和組件的普通屬性

Props、State的概念都很清晰,組件的普通屬性是指在組件中直接掛載到this下的屬性。其實,Props和State也是組件的兩個普通屬性,因為我們可以通過this.propsthis.state 直接獲取到。那么Props、State 和 組件的其他普通屬性,分別應(yīng)該在什么場景下使用呢?

Props和State都是用于組件渲染的,也就是說,一個組件最終長成什么樣,取決于這個組件的Props和State。Props和State的變化都會觸發(fā)組件的render方法。但這兩者也是有區(qū)別的。Props是只讀的數(shù)據(jù),它是由父組件傳遞過來的;而State是組件內(nèi)部自己維護的狀態(tài),是可變的。State可以根據(jù)Props的變化而變化。如果組件中還需要其他屬性,而這個屬性又與組件的渲染無關(guān)(也就是render方法中不會用到),那么就可以把這個屬性直接掛在到this下,而不是作為組件的一個狀態(tài)。

例如,組件中需要一個定時器,每隔幾秒改變一下組件的狀態(tài),就可以定義一個this.timer屬性,以備在componentWillUnmount時,清除定時器。

三、setState 異步性

React官網(wǎng)提到,this.statethis.props的更新可能是異步的,React可能會出于性能考慮,將多個setState的調(diào)用,合并到一次State的更新中。所以,不要依賴this.propsthis.state的值計算下一個狀態(tài)。引用官網(wǎng)的一個代碼示例:

// Wrong
this.setState({
 counter: this.state.counter + this.props.increment,
});

如果一定要這么做,可以使用另一個以函數(shù)作為參數(shù)的setState方法,這個函數(shù)的第一個參數(shù)是前一個State,第二個參數(shù)是當前接收到的最新Props。如下所示:

// Correct
this.setState(function(prevState, props) {
 return {
 counter: prevState.counter + props.increment
 };
});

在調(diào)用setState之后,也不能立即使用this.state獲取最新狀態(tài),因為這時的state很可能還沒有被更新,要想保證獲取到的state是最新的state,可以在componentDidUpdate中獲取this.state。也可以使用帶用回調(diào)函數(shù)參數(shù)版本的setStatesetState(stateChange, [callback]) ,回調(diào)函數(shù)中的this.state會保證是最新的state。

四、componentWillReceiveProps

當組件的屬性可能發(fā)生變化時,這個方法會被調(diào)用。這里說可能,是因為父組件render方法每次被調(diào)用時,子組件的這個方法都會被調(diào)用(子組件第一次初始化時除外),但并不一定每次子組件的屬性都會發(fā)生變化。如果組件的State需要根據(jù)Props的變化而變化,那么這個方法就是最適合這個這個邏輯的地方。例如當Props變化時,組件的State需要重置,就可以在這個方法中調(diào)用this.setState()來重置狀態(tài)。需要注意,在這個方法中調(diào)用this.setState()并不會重新觸發(fā)componentWillReceiveProps的調(diào)用,也不會導致render方法被觸發(fā)兩次。一般情況下,接收到新Props會觸發(fā)一次render,調(diào)用this.setState也會觸發(fā)一次render,但在componentWillReceiveProps中調(diào)用this.setState,React會把原本需要的兩次render,合并成一次。

五、shouldComponentUpdate

這個方法常作為優(yōu)化React性能使用。當shouldComponentUpdate返回false時,組件本次的render方法不會被觸發(fā)??梢酝ㄟ^在這個方法中比較前后兩次state或者props,根據(jù)實際業(yè)務(wù)場景決定是否需要觸發(fā)render方法。

React提供了一個React.PureComponent組件,這個組件重寫了shouldComponentUpdate,會對前后兩次的state和props進行淺比較,如何不一致,才會返回true,觸發(fā)后續(xù)的render方法。這里的淺比較指,只會對state和props的第一級屬性進行比較(使用!==),這滿足一般的使用場景。如果你的組件繼承了React.PureComponent,但在setState時,傳入的state是直接修改的原有state對象,就會因為依然滿足淺比較的條件,而不會重新觸發(fā)render方法,導致最終DOM和state不一致。例如state={books: ['A','B']} ,在setState時,使用this.setState({name: this.state.books.push('C')})直接修改books對象,這樣雖然books內(nèi)容發(fā)生了修改,但因為對象引用并沒有變化,所以依然滿足淺比較條件,不會觸發(fā)render方法。

一般情況下,讓shouldComponentUpdate返回默認的true是不會有太大問題的。雖然這樣可能導致一些不必要的render方法被調(diào)用,但render方法直接操作的是虛擬DOM,只要虛擬DOM沒有發(fā)生變化,并不會導致實體DOM的修改。而JS慢是慢在實體DOM的修改上。只要你的render方法不是很復雜,多調(diào)用幾次render方法并不會帶來多大的性能開銷。

六、render

父組件每次render方法被調(diào)用,或者組件自己每次調(diào)用setState方法,都會觸發(fā)組件的render方法(前提是shouldComponentUpdate使用默認行為,總是返回true)。那么組件每次render,是不是都會導致實體DOM的重新創(chuàng)建呢?答案是,不是!

React之所以比直接操作DOM的JS庫快,原因是React在實體DOM之上,抽象出一層虛擬DOM,render方法執(zhí)行后,得到的是虛擬DOM,React 會把組將當前的虛擬DOM結(jié)構(gòu)和前一次的虛擬DOM結(jié)構(gòu)做比較,只有存在差異性,React才會把差異的內(nèi)容同步到實體DOM上。如果兩次render后的虛擬DOM結(jié)構(gòu)保持一致,并不會觸發(fā)實體DOM的修改。

React速度快的原因,還有一個是它出色的Diff算法。標準的比較兩棵樹的Diff算法的時間復雜是 O(n3) 。而React基于非常符合實際場景的兩個假設(shè),就將Diff算法的時間復雜度降到了接近O(n)。這兩個假設(shè)是:

  • 如果兩個組件或元素類型不同,那么他們就是完全不同的樹,不需要再比較他們的子節(jié)點。例如,<Article>和<Comment>將產(chǎn)生是兩個完全的樹狀結(jié)構(gòu); <div>children</div><p>children</p>也是兩個完全不同的樹。這種情況下,組件會被完全重建,舊的DOM節(jié)點被銷毀,組件經(jīng)歷componentWillUnmount() ,然后重新創(chuàng)建一棵新樹, 組件經(jīng)歷 componentWillMount() componentDidMount() 。
  • 可以為組件或元素設(shè)置key屬性,key用來標識這個組件或元素。key不需要全局唯一,只需要在兄弟組件或兄弟元素間保證唯一性就可以。key常用到集合(List)元素中。

例如:

<ul>
<li key='a'>Book A</li>
<li key='b'>Book B</li>
</ul>

當在第一個位置插入一條記錄Book C 時,

<ul>
<li key='c'>Book C</li>
<li key='a'>Book A</li>
<li key='b'>Book B</li>
</ul>

由于有key的標識,React知道此時新增了一條記錄,會創(chuàng)建一個新的<li>元素,并把它插入到列表中的第一個位置。如果沒有設(shè)置key,React并不知道是新增了一條記錄,還是原來的兩條記錄完全替換成新的三條記錄,或者其他更加復雜的修改場景。React需要自上而下的比較每一條記錄,這樣每次比較節(jié)點都不同,所以需要修改兩次節(jié)點,然后再新增一個節(jié)點,效率明顯要差很多。

這里同時揭露了另一個問題,不要使用元素在集合中的索引值作為key,因為一旦集合中元素順序發(fā)生改變,就可能導致大量的key失效,進而引起大量的修改操作。

如何發(fā)送網(wǎng)絡(luò)請求

當我們需要從服務(wù)器獲取數(shù)據(jù)時,我們應(yīng)該在組件的哪一個生命周期方法中發(fā)送網(wǎng)絡(luò)請求呢?React官網(wǎng)上提到,可以在componentDidMount中發(fā)送網(wǎng)絡(luò)請求,這也是一般情況下的最佳實踐。有些人也會把發(fā)送網(wǎng)絡(luò)請求放在componentWillMount中,并且認為這個方法先于componentDidMount調(diào)用,所以可以更快地獲取數(shù)據(jù)。個人認為,這種使用方法一般也是沒有問題的,但在一些場景下會出現(xiàn)問題,比如需要在服務(wù)器端渲染時,componentWillMount會被調(diào)用兩次,一次是在Server端,一次是在Client端。可參考這篇文章。

總結(jié)

以上就是這篇文章的全部內(nèi)容了,希望本文的內(nèi)容對大家的學習或者工作能帶來一定的幫助,如果有疑問大家可以留言交流,謝謝大家對腳本之家的支持。

相關(guān)文章

  • 解析TypeError:import_react_native.AppState.removeEventListener?is?not?a?function

    解析TypeError:import_react_native.AppState.removeEventListener

    這篇文章主要為大家介紹了TypeError:import_react_native.AppState.removeEventListener?is?not?a?function問題解決分析,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪
    2023-09-09
  • React-router4路由監(jiān)聽的實現(xiàn)

    React-router4路由監(jiān)聽的實現(xiàn)

    這篇文章主要介紹了React-router4路由監(jiān)聽的實現(xiàn),小編覺得挺不錯的,現(xiàn)在分享給大家,也給大家做個參考。一起跟隨小編過來看看吧
    2018-08-08
  • React Ant Design樹形表格的復雜增刪改操作

    React Ant Design樹形表格的復雜增刪改操作

    這篇文章主要介紹了React Ant Design樹形表格的復雜增刪改操作,具有很好的參考價值,希望對大家有所幫助。一起跟隨小編過來看看吧
    2020-11-11
  • 在react中使用vue的狀態(tài)管理的方法示例

    在react中使用vue的狀態(tài)管理的方法示例

    這篇文章主要介紹了在react中使用vue的狀態(tài)管理的方法示例,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧
    2020-05-05
  • React的生命周期詳解

    React的生命周期詳解

    React是用于構(gòu)建用戶界面的JavaScript庫。本文詳細講解了React的生命周期,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧
    2022-06-06
  • 如何在React?Native開發(fā)中防止滑動過程中的誤觸

    如何在React?Native開發(fā)中防止滑動過程中的誤觸

    在使用React?Native開發(fā)的時,當我們快速滑動應(yīng)用的時候,可能會出現(xiàn)誤觸,導致我們會點擊到頁面中的某一些點擊事件,誤觸導致頁面元素響應(yīng)從而進行其他操作,表現(xiàn)出非常不好的用戶體驗。
    2023-05-05
  • 詳解React?Native中如何使用自定義的引用路徑

    詳解React?Native中如何使用自定義的引用路徑

    這篇文章主要為大家介紹了React?Native中如何使用自定義的引用路徑詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪
    2022-10-10
  • 詳解React開發(fā)必不可少的eslint配置

    詳解React開發(fā)必不可少的eslint配置

    本篇文章主要介紹了詳解React開發(fā)必不可少的eslint配置,小編覺得挺不錯的,現(xiàn)在分享給大家,也給大家做個參考。一起跟隨小編過來看看吧
    2018-02-02
  • Remix路由模塊輸出對象loader函數(shù)詳解

    Remix路由模塊輸出對象loader函數(shù)詳解

    這篇文章主要為大家介紹了Remix路由模塊輸出對象loader函數(shù)詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪<BR>
    2023-04-04
  • React中傳遞組件的三種方式小結(jié)

    React中傳遞組件的三種方式小結(jié)

    通過傳遞組件,我們可以將復雜組件內(nèi)部的一部分 UI 交由外部組件來控制渲染,這也是控制反轉(zhuǎn)(Inversion of Control)的一種體現(xiàn),在 React 中,我們可以通過三種方式來傳遞組件,本文就來給大家述說這三種方式,需要的朋友可以參考下
    2023-07-07

最新評論