React總結(jié)篇之七_(dá)Redux和服務(wù)器通信

• React組件訪問服務(wù)器的方式
• Redux架構(gòu)下訪問服務(wù)器的方式

一、React組件訪問服務(wù)器

1. 代理功能訪問API
   

2. React組件訪問服務(wù)器的生命周期

以顯示天氣預(yù)報(bào)為示例：

• 通過服務(wù)器API獲得天氣情況數(shù)據(jù)
• 展示天氣情況數(shù)據(jù)

分兩個(gè)步驟完成：
（1）在裝載過程中，因?yàn)閣eather組件并沒有獲得服務(wù)器結(jié)果，就不顯示結(jié)果?；蛘唢@示一個(gè)’正在裝載‘之類的提示信息，但weather組件這時(shí)候要發(fā)出對(duì)服務(wù)器的請(qǐng)求。
（2）獲取到天氣數(shù)據(jù)之后，顯示出來

在裝載過程中，通常我們?cè)诮M件的componentDidMount函數(shù)中做請(qǐng)求服務(wù)器的事情。

3. React組件訪問服務(wù)器的優(yōu)缺點(diǎn)
   將狀態(tài)放在組件中不是很好的選擇，尤其是當(dāng)組件變得復(fù)雜龐大了之后。Redux是用來幫助管理應(yīng)用狀態(tài)的，應(yīng)該盡量把狀態(tài)存放在Redux Store的狀態(tài)中，而不是放在React組件中。

二、Redux訪問服務(wù)器

1. Redux-thunk中間件
   使用Redux訪問服務(wù)器，同樣要解決的是異步問題。
   Redux的單向數(shù)據(jù)流是同步操作，驅(qū)動(dòng)Redux流程的是action對(duì)象，每一個(gè)action對(duì)象被派發(fā)到Store上之后，同步的被分配給所有的reducer函數(shù)，每個(gè)reducer都是純函數(shù)，純函數(shù)不產(chǎn)生任何副作用，自然是完成數(shù)據(jù)操作之后立刻同步返回，reducer返回的結(jié)果又被同步的拿去更新Store上的狀態(tài)數(shù)據(jù)，更新狀態(tài)數(shù)據(jù)的操作會(huì)立即被同步給監(jiān)聽Store狀態(tài)改變的函數(shù)，從而引發(fā)作為視圖的React組件更新過程。
   在這個(gè)過程中，Redux-chunk可以作為Redux中異步操作的方法之一。
   按照Redux-chunk的想法，在Redux的單向數(shù)據(jù)流中，在action對(duì)象被reducer函數(shù)處理之前，是插入異步功能的時(shí)機(jī)。
   在Redux架構(gòu)下，一個(gè)action對(duì)象在通過store.dispatch派發(fā)，在調(diào)用reducer函數(shù)之前，會(huì)先經(jīng)過一個(gè)中間件環(huán)節(jié)，這就是產(chǎn)生異步操作的時(shí)機(jī)，實(shí)際上Redux-chunk提供的就是一個(gè)Redux中間件，我們需要在創(chuàng)建store時(shí)用上這個(gè)中間件。
   

2. 異步action對(duì)象
   當(dāng)我們想要讓Redux幫忙處理一個(gè)異步操作的時(shí)候，代碼一樣也要派發(fā)一個(gè)action對(duì)象，畢竟Redux單向數(shù)據(jù)流就是由action對(duì)象驅(qū)動(dòng)的，但是這個(gè)引發(fā)異步操作的action對(duì)象比較特殊，我們叫他們’異步action對(duì)象‘。
   有了redux-chunk中間件之后，這些action對(duì)象根本沒有機(jī)會(huì)觸及到reducer函數(shù)，在中間件一層就被redux-chunk截獲。
   redux-chunk的工作是檢查action對(duì)象是不是函數(shù)，如果不是函數(shù)就放行，完成普通action對(duì)象的生命周期，而如果發(fā)現(xiàn)action對(duì)象是函數(shù)，那就執(zhí)行這個(gè)函數(shù)，并把Store的dispatch函數(shù)和getState函數(shù)作為參數(shù)傳遞到函數(shù)中去，處理過程到此為止，不會(huì)讓這個(gè)異步action對(duì)象繼續(xù)往前派發(fā)到reducer函數(shù)。

3. 異步操作的模式
   一個(gè)訪問服務(wù)器的action，至少要涉及3個(gè)action類型：

   • 表示異步操作已經(jīng)開始的action類型，例如：表示一個(gè)請(qǐng)求天氣信息的API請(qǐng)求已經(jīng)發(fā)送給服務(wù)器的狀態(tài)；
   • 表是異步操作成功的action類型，請(qǐng)求天氣信息的API調(diào)用獲得了正確的結(jié)果，就會(huì)引發(fā)這種類型的action；
   • 表示異步操作失敗的action類型，請(qǐng)求天氣信息的API調(diào)用任何一個(gè)環(huán)節(jié)出了錯(cuò)誤，無論是網(wǎng)絡(luò)錯(cuò)誤、本地代理服務(wù)錯(cuò)誤還是遠(yuǎn)程服務(wù)器返回的結(jié)果錯(cuò)誤，都會(huì)引發(fā)這個(gè)類型的action。
     當(dāng)這三種類型的action對(duì)象被派發(fā)時(shí)，會(huì)讓React組件進(jìn)入各自不同的三種狀態(tài)，如：
   • 異步操作正在進(jìn)行中
   • 異步操作已經(jīng)成功完成
   • 任務(wù)操作已經(jīng)失敗
4. 異步操作的終止
   拿天氣預(yù)報(bào)的例子舉例：
   從用戶角度出發(fā)，當(dāng)連續(xù)選擇城市的時(shí)候，總是希望顯示最后一次選中的城市信息，也就是說，一個(gè)更好的辦法是在發(fā)出API請(qǐng)求的時(shí)候，將之前的API請(qǐng)求全部終止作廢，這樣就保證了獲得的有效結(jié)果絕對(duì)是用戶的最后一次選擇結(jié)果。

三、如何挑選異步操作方式

1. 在Redux的單向數(shù)據(jù)流中，什么時(shí)機(jī)插入異步操作？
   Redux的數(shù)據(jù)流轉(zhuǎn)完全靠action來驅(qū)動(dòng)，對(duì)于redux-chunk，切入異步操作的時(shí)機(jī)是在中間件中，但這并不是唯一的位置。
   通過定制化Store Enhancer，可以在action派發(fā)路徑上任何一個(gè)位置插入異步操作，甚至作為純函數(shù)的reducer都可以幫助實(shí)現(xiàn)異步操作。異步操作本身就是一種副作用，reducer的執(zhí)行過程當(dāng)然不應(yīng)該產(chǎn)生異步操作，但是reducer函數(shù)的返回值卻可以包含對(duì)異步操作的’指示‘，也就是說，reducer返回的結(jié)果可以用純數(shù)據(jù)的方式表示需要發(fā)起一個(gè)對(duì)服務(wù)器資源的訪問，由reducer調(diào)用者去真正執(zhí)行這個(gè)訪問服務(wù)器資源的操作，這樣不違背reducer是一個(gè)純函數(shù)的原則。

2. 對(duì)應(yīng)庫的大小如何？
   幾KB-幾十KB

3. 學(xué)習(xí)曲線是不是太陡？
   如果一個(gè)應(yīng)用只有一個(gè)簡單的API請(qǐng)求，使用redux-thunk能解決的話就使用redux-thunk。

4. 是否會(huì)和其他的Redux庫沖突？
   可能會(huì)發(fā)生沖突，使用任何一個(gè)庫在Redux中實(shí)現(xiàn)異步操作，都需要多方面的考慮。

四、利用Promise實(shí)現(xiàn)異步操作
對(duì)于Promise在Redux庫中如何實(shí)現(xiàn)，相關(guān)的庫也很多，但是都很簡單，用一個(gè)Redux中間件就可以實(shí)現(xiàn)：

• redux-promise
• redux-promises
• redux-simple-promise
• redux-promise-middleware