摘要:屬性如何獲取,是容器性組件負責的事情。所以,不要依賴和的值計算下一個狀態。也可以使用帶用回調函數參數版本的,回調函數中的會保證是最新的。當返回時,組件本次的方法不會被觸發。
容器性組件(container component)和展示性組件(presentational component)
使用React編寫組件時,我們需要有意識地將組件劃分為容器性組件(container component)和展示性組件(presentational component),這樣有助于我們在編寫組件時,更加明確這個組件應該負責哪些事情。
容器性組件,負責業務流程邏輯的處理,如發送網絡請求,處理請求數據,將處理過的數據傳遞給子組件的Props使用。同時,容器性組件提供源數據的方法,以Props方式傳遞給子組件,當子組件的狀態變更引起源數據的變化時,子組件通過調用容器性組件提供的方法同步這些變化。
展示性組件,負責組件的外表,也就是組件如何渲染,具有很強的內聚性。展示性組件不關心渲染時使用的組件屬性(Props)是如何獲取到的,它只要知道有了這些Props后,組件應該如何渲染就足夠了。屬性如何獲取,是容器性組件負責的事情。當展示性組件狀態的變化需要同步到源數據時,需要調用容器性組件中的方法,這個方法一般也是通過Props傳遞給展示性組件。
例如,一個Todo項目,有一個Todo組件和一個TodoList組件,Todo組件是一個容器性組件,負責從服務器端獲取待辦事項列表,獲取到待辦事項列表后傳遞給TodoList顯示。當在TodoList中新建一項待辦事項后,需要通過TodoList 的 Props,調用Todo組件中保存待辦項目的方法,將新建的待辦項目同步到服務器端。
容器性組件和展示性組件可以相互嵌套,一個容器性組件可以包含多個展示性組件和其他的容器性組件;一個展示性組將也可以包含容器性組件和其他的展示性組件。這樣的分工,可以使與組件渲染無直接關系的邏輯由容器性組件集中負責,展示性組件只關注組件的渲染邏輯,從而使展示性組件更容易被復用。對于非常簡單的頁面,一般只要一個容器性組件就足夠了;但對于負責頁面,則需要多個容器性組件,否則所有的業務邏輯都在一個容器性組件中處理的話,會導致這個組件非常復雜,同時這個組件獲取到的源數據,可能需要經過很多層的組件Props的傳遞,才能到達最終使用的展示性組件。
Props、State和組件的普通屬性Props、State的概念都很清晰,組件的普通屬性是指在組件中直接掛載到this下的屬性。其實,Props和State也是組件的兩個普通屬性,因為我們可以通過this.props 和 this.state 直接獲取到。那么Props、State 和 組件的其他普通屬性,分別應該在什么場景下使用呢?
Props和State都是用于組件渲染的,也就是說,一個組件最終長成什么樣,取決于這個組件的Props和State。Props和State的變化都會觸發組件的render方法。但這兩者也是有區別的。Props是只讀的數據,它是由父組件傳遞過來的;而State是組件內部自己維護的狀態,是可變的。State可以根據Props的變化而變化。如果組件中還需要其他屬性,而這個屬性又與組件的渲染無關(也就是render方法中不會用到),那么就可以把這個屬性直接掛在到this下,而不是作為組件的一個狀態。
例如,組件中需要一個定時器,每隔幾秒改變一下組件的狀態,就可以定義一個this.timer屬性,以備在componentWillUnmount時,清除定時器。
setState 異步性React官網提到,this.state和this.props的更新可能是異步的,React可能會出于性能考慮,將多個setState的調用,合并到一次State的更新中。所以,不要依賴this.props 和 this.state的值計算下一個狀態。引用官網的一個代碼示例:
// Wrong this.setState({ counter: this.state.counter + this.props.increment, });
如果一定要這么做,可以使用另一個以函數作為參數的setState方法,這個函數的第一個參數是前一個State,第二個參數是當前接收到的最新Props。如下所示:
// Correct this.setState(function(prevState, props) { return { counter: prevState.counter + props.increment }; });
在調用setState之后,也不能立即使用this.state獲取最新狀態,因為這時的state很可能還沒有被更新,要想保證獲取到的state是最新的state,可以在componentDidUpdate中獲取this.state。也可以使用帶用回調函數參數版本的setStatesetState(stateChange, [callback]),回調函數中的this.state會保證是最新的state。
componentWillReceiveProps當組件的屬性可能發生變化時,這個方法會被調用。這里說可能,是因為父組件render方法每次被調用時,子組件的這個方法都會被調用(子組件第一次初始化時除外),但并不一定每次子組件的屬性都會發生變化。如果組件的State需要根據Props的變化而變化,那么這個方法就是最適合這個這個邏輯的地方。例如當Props變化時,組件的State需要重置,就可以在這個方法中調用this.setState()來重置狀態。需要注意,在這個方法中調用this.setState()并不會重新觸發componentWillReceiveProps的調用,也不會導致render方法被觸發兩次。一般情況下,接收到新Props會觸發一次render,調用this.setState也會觸發一次render,但在componentWillReceiveProps中調用this.setState,React會把原本需要的兩次render,合并成一次。
shouldComponentUpdate這個方法常作為優化React性能使用。當shouldComponentUpdate返回false時,組件本次的render方法不會被觸發。可以通過在這個方法中比較前后兩次state或者props,根據實際業務場景決定是否需要觸發render方法。
React提供了一個React.PureComponent組件,這個組件重寫了shouldComponentUpdate,會對前后兩次的state和props進行淺比較,如何不一致,才會返回true,觸發后續的render方法。這里的淺比較指,只會對state和props的第一級屬性進行比較(使用!==),這滿足一般的使用場景。如果你的組件繼承了React.PureComponent,但在setState時,傳入的state是直接修改的原有state對象,就會因為依然滿足淺比較的條件,而不會重新觸發render方法,導致最終DOM和state不一致。例如state={books: ["A","B"]},在setState時,使用this.setState({name: this.state.books.push("C")})直接修改books對象,這樣雖然books內容發生了修改,但因為對象引用并沒有變化,所以依然滿足淺比較條件,不會觸發render方法。
一般情況下,讓shouldComponentUpdate返回默認的true是不會有太大問題的。雖然這樣可能導致一些不必要的render方法被調用,但render方法直接操作的是虛擬DOM,只要虛擬DOM沒有發生變化,并不會導致實體DOM的修改。而JS慢是慢在實體DOM的修改上。只要你的render方法不是很復雜,多調用幾次render方法并不會帶來多大的性能開銷。
render父組件每次render方法被調用,或者組件自己每次調用setState方法,都會觸發組件的render方法(前提是shouldComponentUpdate使用默認行為,總是返回true)。那么組件每次render,是不是都會導致實體DOM的重新創建呢?答案是,不是!
React之所以比直接操作DOM的JS庫快,原因是React在實體DOM之上,抽象出一層虛擬DOM,render方法執行后,得到的是虛擬DOM,React 會把組將當前的虛擬DOM結構和前一次的虛擬DOM結構做比較,只有存在差異性,React才會把差異的內容同步到實體DOM上。如果兩次render后的虛擬DOM結構保持一致,并不會觸發實體DOM的修改。
React速度快的原因,還有一個是它出色的Diff算法。標準的比較兩棵樹的Diff算法的時間復雜是 O(n3) 。而React基于非常符合實際場景的兩個假設,就將Diff算法的時間復雜度降到了接近O(n)。這兩個假設是:
如果兩個組件或元素類型不同,那么他們就是完全不同的樹,不需要再比較他們的子節點。例如,和
children
也是兩個完全不同的樹。這種情況下,組件會被完全重建,舊的DOM節點被銷毀,組件經歷componentWillUnmount(),然后重新創建一棵新樹, 組件經歷 componentWillMount() 和 componentDidMount()。可以為組件或元素設置key屬性,key用來標識這個組件或元素。key不需要全局唯一,只需要在兄弟組件或兄弟元素間保證唯一性就可以。key常用到集合(List)元素中。例如:
當在第一個位置插入一條記錄Book C 時,
由于有key的標識,React知道此時新增了一條記錄,會創建一個新的元素,并把它插入到列表中的第一個位置。如果沒有設置key,React并不知道是新增了一條記錄,還是原來的兩條記錄完全替換成新的三條記錄,或者其他更加復雜的修改場景。React需要自上而下的比較每一條記錄,這樣每次比較節點都不同,所以需要修改兩次節點,然后再新增一個節點,效率明顯要差很多。
這里同時揭露了另一個問題,不要使用元素在集合中的索引值作為key,因為一旦集合中元素順序發生改變,就可能導致大量的key失效,進而引起大量的修改操作。
如何發送網絡請求當我們需要從服務器獲取數據時,我們應該在組件的哪一個生命周期方法中發送網絡請求呢?React官網上提到,可以在componentDidMount中發送網絡請求,這也是一般情況下的最佳實踐。有些人也會把發送網絡請求放在componentWillMount中,并且認為這個方法先于componentDidMount調用,所以可以更快地獲取數據。個人認為,這種使用方法一般也是沒有問題的,但在一些場景下會出現問題,比如需要在服務器端渲染時,componentWillMount會被調用兩次,一次是在Server端,一次是在Client端。可參考這篇文章。
歡迎關注我的公眾號:老干部的大前端,領取21本大前端精選書籍!
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/84216.html
摘要:半路出家的前端程序員應該不在少數,我也是其中之一。年,馮馮同事兼師兄看我寫太費勁,跟我說對面樓在找,問我要不要學,說出來可能有點丟人,但是在那之前,我真得不知道什么是,什么是。 半路出家的前端程序員應該不在少數,我也是其中之一。 為何會走向前端 非計算機專業的我,畢業之后,就職于一家電力行業公司,做過設備調試、部門助理、測試,也寫過一段時間的QT,那三年的時間,最難過的不是工作忙不忙,...
摘要:支持回調函數,當內的表單輸入發生變化時可以即時通知其父組件。這是第一個問題,為了解決這個問題呢,需要對它的提兩個條件屬性上必須要接收一個回調函數,函數接收一個對象參數,參數結構如下的值為當前項產出的數據,可能是個對象也可能是字符串或者數值。 前言 最近在寫一個面向 React 初學者的系列教程玩轉 React,內容對有 React 開發經驗的同學來說可能太過于基礎和啰嗦,不太感興趣。所...
摘要:支持回調函數,當內的表單輸入發生變化時可以即時通知其父組件。這是第一個問題,為了解決這個問題呢,需要對它的提兩個條件屬性上必須要接收一個回調函數,函數接收一個對象參數,參數結構如下的值為當前項產出的數據,可能是個對象也可能是字符串或者數值。 前言 最近在寫一個面向 React 初學者的系列教程玩轉 React,內容對有 React 開發經驗的同學來說可能太過于基礎和啰嗦,不太感興趣。所...
摘要:循環可以使用的范圍包括數組和結構某些類似數組的對象對象,以及字符串。只能遍歷數組,不能中斷,返回值是修改后的數組。除了之外,等,也有同樣的問題。聲明一個只讀的常量。這在語法上,稱為暫時性死區。暫時性死區也意味著不再是一個百分百安全的操作。 互聯網寒冬之際,各大公司都縮減了HC,甚至是采取了裁員措施,在這樣的大環境之下,想要獲得一份更好的工作,必然需要付出更多的努力。 一年前,也許你搞清楚閉包...
摘要:只能遍歷數組,不能中斷,返回值是修改后的數組。這在語法上,稱為暫時性死區。作用域鏈無論是還是查詢,都會在當前的作用域開始查找,如果沒有找到,就會向上級作用域繼續查找目標標識符,每次上升一個作用域,一直到全局作用域為止。 互聯網寒冬之際,各大公司都縮減了HC,甚至是采取了裁員措施,在這樣的大環境之下,想要獲得一份更好的工作,必然需要付出更多的努力。 一年前,也許你搞清楚閉包,this,原...
閱讀 908·2023-04-25 18:51
閱讀 1863·2021-09-09 11:39
閱讀 3276·2019-08-30 15:53
閱讀 2090·2019-08-30 13:03
閱讀 1304·2019-08-29 16:17
閱讀 574·2019-08-29 11:33
閱讀 1878·2019-08-26 14:00
閱讀 2118·2019-08-26 13:41