《深入淺出React和Redux》(4) - 服務器通信、單元測試

與服務器通信

與服務器通信的時長不可控，需要採用異步的形式，可以使用js的fetch函數來調用api。

fetch函數

fetch函數的基本使用形式爲：

fetch(apiUrl).then((response) => {
  if (response.status !== 200) {
    throw new Error('Fail to get response with status ' + response.status);
  }

  response.json().then((responseJson) => {
    this.setState(...);
  }).catch((error) => {
    this.setState(...);
  });
}).catch((error) => {
  this.setState(...);
});

以純react（沒有引入redux）的代碼爲例，fetch函數執行時會立即返回一個Promise類型的對象，所以要接then和catch，只要服務器返回的是合法的HTTP響應（包括500、400），都會觸發then調用，所以在then回調函數中還需要判斷status是否爲200。此外，即使在response.status爲200時，也不能直接讀取response中的內容，因爲fetch在接收到HTTP響應的報頭部分就會調用then，而不是等到整個HTTP響應完成。所以爲了獲取到body，還需要繼續調用json()並針對其返回的Promise提供回調函數。在終於成功獲取到服務器返回的內容後，通過觸發狀態的變化引發頁面的重新渲染。

redux-thunk中間件

redux的單向數據流是同步操作，如何實現調用服務器這樣的異步操作呢？可以使用redux-thunk中間件。

npm install --save redux-thunk

在Redux架構下，一個action對象在通過store.dispatch派發，在調用reducer函數之前，會先經過一箇中間件的環節，這就是產生異步操作的機會。

要產生異步操作要發送異步action對象，與普通的action對象不同，它並沒有type字段，而且它是一個函數。而redux-thunk的工作是檢查action對象是不是函數，如果不是函數就放行，完成普通action對象的生命週期，而如果發現action對象是函數，那就執行這個函數，並把Store的dispatch函數和getState函數作爲參數傳遞到函數中去，處理過程到此爲止，不會讓這個異步action對象繼續往前派發到reducer函數。 createStore時，將redux-thunk中間件作爲storeEnhancer之一傳入：

const middlewares = [thunkMiddleware];

const storeEnhancers = compose(
  applyMiddleware(...middlewares),
  (win && win.devToolsExtension) ? win.devToolsExtension() : (f) => f,
);

export default createStore(reducer, {}, storeEnhancers);

異步操作有固定的模式，首先定義三種action類型，分別表示異步操作開始、成功、失敗：

export const FETCH_STARTED = 'WEATHER/FENTCH_STARTED';
export const FETCH_SUCCESS = 'WEATHER/FENTCH_SUCCESS';
export const FETCH_FAILURE = 'WEATHER/FENTCH_FAILURE';

然後定義生成異步action的函數，這個函數會被redux-thunk截獲並調用，調用時傳遞的參數是dispatch函數和getState函數：

export const sampleAsyncAction = ()=>{
  return (dispatch, getState) => {
    
    // 在這裏dispatch FETCH_STARTED action

    return fetch(apiUrl).then((response) => {
      if (response.status !== 200) {
        throw new Error('Fail to get response with status ' + response.status);
      }

      response.json().then((responseJson) => {
        // 在這裏dispatch FETCH_SUCCESS action
      }).catch((error) => {
        
      });
    }).catch((error) => {
        // 在這裏dispatch FETCH_FAILURE action
    });
  }
}

終止異步操作

在頁面與服務端交互過程中，往往會有一次請求還沒結束就發出下一次請求的情況，比如在選擇一個下拉項後調用API加載數據，如果數據還沒加載完成，就切換到別的下拉項，會發生什麼，這取決於兩次請求的返回順序，如果第一次請求先返回，那麼頁面會先顯示第一次的響應結果，再刷新爲第二次的，整體來說問題不大；但是如果第二次的請求先於第一次的返回，那麼頁面顯示的最終結果就與下拉項不匹配了。對於這種場景，簡單點可以通過加載數據時禁用下拉框來解決，但這種做法的用戶體驗較差，如果服務端一直沒有響應，下拉框就一直處於禁用狀態；還有更合理的一種做法時，在發出下一次API請求時，終止上一次的API請求。

可惜ES6的標準中，Promise對象是無法中斷的，爲此可以通過應用層的修改來丟棄上一次的請求。以fetchWeather異步action舉例：

export const fetchWeather = (cityCode) => {
    return (dispatch) => {
        const seqId=++nextSeqId;

        const dispatchIfValid=(action)=>{
            if(seqId===nextSeqId){
                return dispatch(action);
            }
        }

        dispatchIfValid(fetchWeatherStarted());

        const apiUrl = `/data/cityinfo/${cityCode}.html`;

        // dispatch(fetchWeatherStarted());

        return fetch(apiUrl).then((response) => {
            if (response.status !== 200) {
                throw new Error('Fail to get response with status ' + response)
            }
            response.json().then((response) => {
                dispatchIfValid(fetchWeatherSuccess(response.weatherinfo));
            }).catch((error) => {
                throw new Error('Invalid js on response: ' + error);
            });
        }).catch((error) => {
            dispatchIfValid(fetchWeatherFailure(error));
        });
    }
};

在action構造函數文件中定義一個文件模塊級的nextSeqId變量，這是一個遞增的整數數字，給每一個訪問API的請求做序列編號。在fetchWeather返回的函數中，fetch開始一個異步請求之前，先給nextSeqId自增加一，然後自增的結果賦值給一個局部變量seqId，這個seqId的值就是這一次異步請求的編號，如果隨後還有fetchWeather構造器被調用，那麼nextSeqId也會自增，新的異步請求會分配爲新的seqId。

然後，action構造函數中所有的dispatch函數都被替換爲一個新定義的函數dispatchIfValid，這個dispatchIfValid函數會檢查當前環境的seqId是否等同於全局的nextSeqId。如果相同，說明fetchWeather沒有被再次調用，就繼續使用dispatch函數。如果不相同，說明這期間有新的fetchWeather被調用，也就是有新的訪問服務器的請求被髮出去了，這時候當前seqId代表的請求就已經過時了，直接丟棄掉，不需要dispatch任何action。

單元測試

關於單元測試框架的選擇，由於在create-react-app創建的應用中已經自帶了Jest庫，所以就直接使用Jest。 Jest會自動在當前目錄下尋找文件名以.test.js爲後綴的文件和存放在__test__目錄下的代碼文件，來執行單元測試。 單元測試代碼的組織方式，通常有兩種模式：

把全部測試代碼放在與src平行的test目錄，在test目錄下建立和src對應子目錄結構，每個單元測試文件都加上test.js後綴，這種方法可以保持src目錄的整潔，但缺點是單元測試中引用功能代碼的路徑會比較長；
在src的子目錄下創建__test__目錄，用於存放對應這個目錄的單元測試，這種方法的優缺點與第一種相反。

React & Redux 應用的測試對象主要有action構造函數、reducer、view，其中reducer、普通的action構造函數都是純函數，非常便於測試。但異步action的構造函數和view的測試相對比較複雜。

異步action的構造函數的測試

一個異步action對象就是一個函數，需要結合redux-thunk之類的中間件才能發揮作用，異步action被派發之後，會連續派發另外兩個action對象代表fetch開始和fetch結束，單元測試要做的就是驗證這樣的行爲。中間件的應用和action的dispatch都涉及到Redux Store，但單元測試中並不需要創建一個完整功能的Store，也不應該進行真實的網絡訪問。所以需要一些測試輔助工具。其中可以使用redux-mock-store來創建一個mock store：

npm install -save-dev redux-mock-store

使用sinon來“篡改”fetch函數的行爲，使其不會發出真實的網絡請求：

npm install -save-dev sinon

然後就可以開始測試了，首先需要做一些準備工作：

Create Mock Store

import thunk from 'redux-thunk';
import configureStore from 'redux-mock-store';
const middlewares = [thunk];
const createMockStore = configureStore(middlewares);
...
const store = createMockStore();

Create Mock Store後，就可以像真實store一樣在其上dispatch action了。

“篡改”fetch函數的行爲

import { stub } from 'sinon';
...
let stubbedFetch;

beforeEach(() => {
  stubbedFetch = stub(global, 'fetch');
});

afterEach(() => {
  stubbedFetch.restore();
});

const mockResponse = Promise.resolve({
  status: 200,
  json: () => Promise.resolve({
    weatherinfo: {}
  })
});
stubbedFetch.returns(mockResponse);

使用sinon的stub函數來覆蓋fetch的返回結果，單元測試用例之間應該互不影響，所以stubbedFetch應該在beforeEach中執行，並在測試用例跑完時執行afterEach時恢復stub行爲。

React組件的測試

測試React組件，測試的是渲染結果、事件處理。但並不是所有的測試過程都需要把React組件的DOM樹都渲染出來，尤其對於包含複雜子組件的React組件，如果深入渲染整個DOM樹，那就要渲染所有子組件，可是子組件可能會有其他依賴關係，比如依賴於某個React Context值，爲了渲染這樣的子組件需要耗費很多精力準備測試環境，這種情況下針對目標組件的測試只要讓它渲染頂層組件就好了，不需要測試子組件。測試React組件可以藉助Enzyme，它由AirBnb開源，enzyme依賴react-addons-test-utils，要一起安裝：

npm install -save-dev enzyme react-addons-test-utils

Enzyme支持三種渲染方法：

shallow，只渲染頂層React組件，不渲染子組件，適合只測試React組件的渲染行爲；
mount，渲染完整的React組件包括子組件，藉助模擬的瀏覽器環境完成事件處理功能；
render，渲染完整的React組件，但是隻產生HTML，並不進行事件處理。

無狀態React組件的測試，可以使用shallow方法只渲染一層，忽略子組件是爲了簡化測試過程。舉例：

const wrapper = shallow(<Filter />);
expect(wrapper.contains(<Link filter={FilterTypes.ALL}> {FilterTypes.ALL} </Link>)).toBe(true);

被連接的React組件的測試，被連接的React組件是指狀態保存在Redux的Store上，並通過connect函數產生的組件，這種組件使用時需要包裹在Provider中，測試的時候也一樣，而且還會測試事件處理、action dispatch後引發視圖的變化，所以這裏需要使用真實的store。

import { Provider } from 'react-redux';
...

const subject = (
  <Provider store={store}>
    <待測組件 />
  </Provider>);

參考書籍

《深入淺出React和Redux》程墨

《深入淺出React和Redux》(4) - 服務器通信、單元測試

與服務器通信

fetch函數

redux-thunk中間件

終止異步操作

單元測試

異步action的構造函數的測試

React組件的測試

參考書籍

自學編程兩個月，現在我月入 4 萬元

Google Chrome驅動程序 124.0.6367.62（正式版本）去哪下載？

前端面試題 - 元素的innerText outerText innerHTML的區別？

前端面試題 - 在HTML5中DOCTYPE的作用是什麼？標準與兼容模式（混雜模式）各有什麼區別？

大模型區域落地再加速！百度“文心中國行”西部首站落地成都錦江

「實戰應用」如何用圖表控件LightningChart創建2D氣泡圖

DevExpress XAF (WinForms UI)賦能醫療管理系統，讓操作更自動化！

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結