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