1.元件掛載階段通訊
react元件的正常運轉本質上是元件不同生命週期方法的有序執行，因此元件與伺服器的通訊也必定依賴元件的生命週期方法。我們先
來看一下元件在掛載階段如何與伺服器通訊。
定義乙個userlistcontainer元件，需要從伺服器獲取使用者列表：
class userlistcontainer extends react.component )
componentwillmount會在元件被掛載前呼叫，因此從時間上來講， 在componentwillmount中執行伺服器通訊要早於在componentdidmount中執行，執行得越早意味著伺服器資料越能更快地返回元件。這也是很多人青睞在componentwillmount中執行伺服器通訊的重要原因。但實際上，componentwillmount與componentdidmount執行的時間差微乎其微，完全可以忽略不計。
componentdidmount是執行元件與伺服器通訊的最佳地方，原因主 要有兩個：
(1)在componentdidmount中執行伺服器通訊可以保證獲取到資料 時，元件已經處於掛載狀態，這時即使要直接操作dom也是安全的，
而componentwillmount無法保證這一點。
(2)當元件在伺服器端渲染時(本書不涉及伺服器渲染內容)，componentwillmount會被呼叫兩次，一次是在伺服器端，另一次是在瀏
覽器端，而componentdidmount能保證在任何情況下只會被呼叫一次，從而不會傳送多餘的資料請求。有些開發人員會在元件的建構函式中執行伺服器通訊，一般情況下，這種方式也可以正常工作。但是，建構函式的意義是執行元件的初始化工作，如設定元件的初始狀態，並不適合做資料請求這類有「***」的工作。因此，不推薦在建構函式中執行伺服器通訊。
2.元件更新階段通訊
元件在更新階段常常需要再次與伺服器通訊，獲取伺服器上的最新資料。例如，元件需要以props中的某個屬性作為與伺服器通訊時的請
求引數，當這個屬性值發生更新時，元件自然需要重新與伺服器通訊。回想2.3節中對元件生命週期的介紹，不難發現componentwillreceiveprops非常適合做這個工作。假設userlistcontainer在獲取使用者列表時還需要乙個引數category，用來根據使用者的職業做篩選，category這個引數是從props中獲取的，實現**如下：
class userlistcontainer extends react.component)
這裡還有乙個地方要注意，在執行fetch請求時，要先對新老props 中的category做比較，只有不一致才說明category有了更新，才需要重新
進行伺服器通訊。componentwillreceiveprops的執行並不能保證props一定發生了修改。
react元件渲染原理
jsx 經過babel編譯成react.createelement的表示式。element在react裡，是組成虛擬dom 樹的節點，用來描述在瀏覽器上看到什麼。它的引數有三個 1 type 標籤 2 attributes 標籤屬性，沒有的話，可以為null 3 children 標籤的子節點 e....
React元件及渲染
首先來說一下什麼是react元件，它其實是頁面上的一部分，例如標題 搜尋框 按鈕等都可以是乙個元件。react的元件又分為函式元件 和class元件。函式元件定義可以如下 這是乙個函式元件，它的本質其實是j ascript函式。它接收唯一帶有資料的 props 代表屬性 物件與並返回乙個react元...
react 八 父元件渲染，子元件不渲染
父元件渲染，子元件跟著渲染，不論引數是否變化，這是個坑 解決思路 步驟一 將html內容新增到狀態變數 constructor 步驟二 在render中將html替換成狀態變數 步驟三 觸發子元件渲染時，設定狀態變數 handlescroll 底部元件響應樣式 scrolltop 900?local...