與服務器通信
與服務器通信的時長不可控，需要采用異步的形式，可以使用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》 程墨
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/262866.html
標籤：JavaScript