實戰 | React開發進階實踐

React已經火到不行了，相信你們夥兒或多或少的看過或者本身動手實踐過一些demo，因此關於一些基礎的概念我這裏就再也不贅述，你們能夠在km或者google上搜索「React入門」。網上的大多數demo都是靜態渲染的例子，只是玩具，並不能很好的體現實際開發過程。興趣部落PC版在生產環境採用了React，這裏給你們分享一下PC部落實戰過程當中，我的以爲比較重要的一些點。

本文分三個部分。

1. React生命週期

2. 跨組件通訊

3. 實際場景應用

---

React生命週期

React只是一個view層的框架，它什麼功能都不提供(相對於Angular的完整性)，實際開發中的需求萬紫千紅，須要靈活多變，React自身提供了一套完美的生命週期接口，讓咱們能夠爲所欲爲。關於React生命週期的理解，咱們能夠把它理解爲遊戲裏打造裝備的過程。先腦補一下裝備打造的過程

收集原材料 -> 加工原材料 -> 鐵匠鋪打造 -> 完成初級裝備 -> 打boss得到高級材料 -> 對比新材料與舊材料的差異 -> 發現更好，加工新材料 -> 鐵匠鋪打造 -> 升級爲高級裝備 -> 等級太高，裝備不適用，分解或給NPC

嗯,基本是這個樣子。

其實，React的生命週期與它有殊途同歸之處(設計模式無處不在啊)。ok，咱們來看下React的生命週期。
官方文檔寫的很清楚，React生命週期分爲3個過程。

Mouting

收集材料，打造一件初級裝備

1. getInitialState

   (收集原材料)
   初始化state數據，只會調用一次

2. componentWillMount

   (加工原材料)
   組件掛載前調用,諧音 「餵馬」

3. render

   (鐵匠鋪打造)
   組裝虛擬DOM，而後渲染到頁面上

4. componentDidMount

   (完成初級裝備)
   掛載完成，能夠訪問dom元素了。

Update(更新)

打boss，用得到的高級材料來升級裝備

1. componentWillReceiveProps

   (得到高級原材料)
   接受到新的props時調用

2. shouldComponentUpdate

   (對比原材料是否更好)
   是否須要更新DOM

3. componentWillUpdate

   (加工原材料)
   更新以前調用

4. render

   (鐵匠鋪打造)
   組裝虛擬DOM，而後渲染到頁面上

5. componentDidUpdate

   (完成高級裝備)
   更新完成

UnMounting(卸載）

淘汰裝備，釋放內存

1. componentWillUnmount

   React作組件卸載時會自動移除掉組件上的事件綁定，可是咱們本身經過原生方法綁定的事件就須要經過componentWillUnmount來自行解綁了

能夠很清晰的看到，在componentDidMount和componentDidUpdate方法中咱們能夠去獲取到dom對象，這個時間點能夠用第三方框架了，好比初始化視頻、音樂播放器等用react比較難造的輪子。

理解透了生命週期，基本上咱們就能夠快樂的去開發了。

---

跨組件通訊

生命週期都是一個組件本身玩，實際開發中咱們是須要跟小夥伴一塊兒玩兒的，那組件之間怎麼交流呢？

交流的對象： 父子組件交流、無關聯組件交流

1. 父組件調用子組件

經過React提供的ref屬性，直接調用子組件的實例

2. 子組件調用父組件

父組件給子組件傳遞的props裏能夠是函數，子組件可直接調用

3. 無直接關係的組件調用

這個就相對複雜一些了。react組件對外都是一個黑盒，常規方法調用，可能須要***不少耦合代碼。有經驗的程序猿應該很快能想到用pub/sub的設計模式來解決這個問題。對，咱們就是要採用這樣模式，可是咱們在多人模式下寫pubsub時，不少時候pubsub散落在各地，維護很苦逼。
React提供了一個基於pub/sub的Flux架構，可讓咱們很清晰的瞭解整個訂閱發佈的過程，維護起來也相對輕鬆。

Flux倡導的是單向數據流的原則，在這種架構下，經過Store存放應用程序的狀態數據。當應用狀態發生變化時，Store 能夠發出事件，通知應用的組件並進行組件的從新渲染。另外，Dispatcher起到中央hub的做用，它爲組件（View）和Store構建 起了橋樑。此外，你能夠在組件上調用action，它會向Store發起事件。Store正是經過訂閱這些事件，並根據事件的觸發來改變 應用程序的內部狀態的

興趣部落採用的Reflux，Reflux是基於flux架構實現的單向數據流類庫，使用很是的便捷。

網上關於flux與reflux原理的講解很是多，我這裏就再也不贅述，有興趣的同窗能夠自行搜索。

---

案例分析

吃透了生命週期，瞭解了跨組件數據通訊，再學點jsx的語法，基本咱們就能夠無限造輪子了(用了React後，你須要造很是很是多的輪子)。咱們來看看興趣部落裏的一些場景的實現

1. 滾動加載

流程是這樣子的：

那這個過程對應到生命週期是什麼樣子的呢？

(有些地方沒有標註上對應的週期方法，圖會畫的太複雜…)

來看看代碼吧。(部分代碼是僞代碼)

這個例子算是比較常見的，你們能夠再根據它體會一下生命週期，經常使用的方法都這個示例裏都有涉及。

2. 跨組件通訊場景: 回覆評論後，在評論列表底部顯示剛剛發表的評論。

這裏有兩個組件：列表組件和評論組件
在評論發表成功後如何通知到列表組件來更新呢,沒什麼好說的，直接看代碼吧。

---

其餘

可能會有人問我爲何不用redux而用reflux

1. 咱們開始預研的時候redux還沒出世，而reflux是當時最火的flux框架

2. 從開始看reflux到使用reflux，我只用了1個小時而redux我看了一成天文檔都暈乎乎的(我太愚鈍(┬＿┬))

對於reflux的使用，也有兩種流派：

1. 全部的異步數據加載(ajax拉取cgi數據)都在store裏進行，而後派發給組件

2. 數據加載放在組件內進行，reflux只用於跨組件通訊。第一種讓整個架構看起來更像MVC，流程也比較清晰。而我我的更偏向於第二種，這樣能夠保證一個組件的完整性，組件的插拔會變的很輕鬆，對於組件的複用及維護也更便利。但也不能徹底這樣，對於多個組件共享一份數據源的狀況，仍是在store加載並派發比較合適，根據實際業務狀況來定奪。