1. 程式人生 > >React總結篇之七_Redux和伺服器通訊

React總結篇之七_Redux和伺服器通訊

  • React元件訪問伺服器的方式
  • Redux架構下訪問伺服器的方式

一、React元件訪問伺服器

  1. 代理功能訪問API
    React總結篇之七_Redux和伺服器通訊

  2. React元件訪問伺服器的生命週期

以顯示天氣預報為示例:

  • 通過伺服器API獲得天氣情況資料
  • 展示天氣情況資料

分兩個步驟完成:
(1)在裝載過程中,因為weather元件並沒有獲得伺服器結果,就不顯示結果。或者顯示一個’正在裝載‘之類的提示資訊,但weather元件這時候要發出對伺服器的請求。
(2)獲取到天氣資料之後,顯示出來

在裝載過程中,通常我們在元件的componentDidMount函式中做請求伺服器的事情。

  1. React元件訪問伺服器的優缺點
    將狀態放在元件中不是很好的選擇,尤其是當元件變得複雜龐大了之後。Redux是用來幫助管理應用狀態的,應該儘量把狀態存放在Redux Store的狀態中,而不是放在React元件中。

二、Redux訪問伺服器

  1. Redux-thunk中介軟體
    使用Redux訪問伺服器,同樣要解決的是非同步問題。
    Redux的單向資料流是同步操作,驅動Redux流程的是action物件,每一個action物件被派發到Store上之後,同步的被分配給所有的reducer函式,每個reducer都是純函式,純函式不產生任何副作用,自然是完成資料操作之後立刻同步返回,reducer返回的結果又被同步的拿去更新Store上的狀態資料,更新狀態資料的操作會立即被同步給監聽Store狀態改變的函式,從而引發作為檢視的React元件更新過程。
    在這個過程中,Redux-chunk可以作為Redux中非同步操作的方法之一。
    按照Redux-chunk的想法,在Redux的單向資料流中,在action物件被reducer函式處理之前,是插入非同步功能的時機。
    在Redux架構下,一個action物件在通過store.dispatch派發,在呼叫reducer函式之前,會先經過一箇中間件環節,這就是產生非同步操作的時機,實際上Redux-chunk提供的就是一個Redux中介軟體,我們需要在建立store時用上這個中介軟體。
    React總結篇之七_Redux和伺服器通訊

  2. 非同步action物件
    當我們想要讓Redux幫忙處理一個非同步操作的時候,程式碼一樣也要派發一個action物件,畢竟Redux單向資料流就是由action物件驅動的,但是這個引發非同步操作的action物件比較特殊,我們叫他們’非同步action物件‘。
    有了redux-chunk中介軟體之後,這些action物件根本沒有機會觸及到reducer函式,在中介軟體一層就被redux-chunk截獲。
    redux-chunk的工作是檢查action物件是不是函式,如果不是函式就放行,完成普通action物件的生命週期,而如果發現action物件是函式,那就執行這個函式,並把Store的dispatch函式和getState函式作為引數傳遞到函式中去,處理過程到此為止,不會讓這個非同步action物件繼續往前派發到reducer函式。

  3. 非同步操作的模式
    一個訪問伺服器的action,至少要涉及3個action型別:

    • 表示非同步操作已經開始的action型別,例如:表示一個請求天氣資訊的API請求已經發送給伺服器的狀態;
    • 表是非同步操作成功的action型別,請求天氣資訊的API呼叫獲得了正確的結果,就會引發這種型別的action;
    • 表示非同步操作失敗的action型別,請求天氣資訊的API呼叫任何一個環節出了錯誤,無論是網路錯誤、本地代理服務錯誤還是遠端伺服器返回的結果錯誤,都會引發這個型別的action。
      當這三種類型的action物件被派發時,會讓React元件進入各自不同的三種狀態,如:
    • 非同步操作正在進行中
    • 非同步操作已經成功完成
    • 任務操作已經失敗
  4. 非同步操作的終止
    拿天氣預報的例子舉例:
    從使用者角度出發,當連續選擇城市的時候,總是希望顯示最後一次選中的城市資訊,也就是說,一個更好的辦法是在發出API請求的時候,將之前的API請求全部終止作廢,這樣就保證了獲得的有效結果絕對是使用者的最後一次選擇結果。

三、如何挑選非同步操作方式

  1. 在Redux的單向資料流中,什麼時機插入非同步操作?
    Redux的資料流轉完全靠action來驅動,對於redux-chunk,切入非同步操作的時機是在中介軟體中,但這並不是唯一的位置。
    通過定製化Store Enhancer,可以在action派發路徑上任何一個位置插入非同步操作,甚至作為純函式的reducer都可以幫助實現非同步操作。非同步操作本身就是一種副作用,reducer的執行過程當然不應該產生非同步操作,但是reducer函式的返回值卻可以包含對非同步操作的’指示‘,也就是說,reducer返回的結果可以用純資料的方式表示需要發起一個對伺服器資源的訪問,由reducer呼叫者去真正執行這個訪問伺服器資源的操作,這樣不違背reducer是一個純函式的原則。

  2. 對應庫的大小如何?
    幾KB-幾十KB

  3. 學習曲線是不是太陡?
    如果一個應用只有一個簡單的API請求,使用redux-thunk能解決的話就使用redux-thunk。

  4. 是否會和其他的Redux庫衝突?
    可能會發生衝突,使用任何一個庫在Redux中實現非同步操作,都需要多方面的考慮。

四、利用Promise實現非同步操作
對於Promise在Redux庫中如何實現,相關的庫也很多,但是都很簡單,用一個Redux中介軟體就可以實現:

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