What
koa-mock-swich是一個前端mock資料、並可以管理返回資料的server。
Why
為什麼需要koa-mock-switch。
目前開發過程中的mock資料方式，主流來說分為：
1.後端mock資料
即，局域環境有一個專門模擬資料用的資料庫，然後，後端開發完介面以後，和線上一樣地進行增刪改查，最後返回給前端資料。
缺點：
時間上，前端在需要資料介面的時候，不得不等後端開發完介面以後，才能進行下一步開發。 職責上，即使前端開發頁面的效率很高，但是因為最後完成的時間肯定是在後端之後的，如果一個專案進度耽誤了，前端的鍋是背定了。
2.前端搭建mock資料服務
我們前端，一般都會自己用express或者koa搭建自己的本地前端mock資料服務，市面上也有很多現成的npm可以使用。
優點:
前後端並行開發。前後端只需要在開發之前，一起定義好介面規範即可。之後前端按照api文件模擬mock資料，自己可以躲在小黑屋獨自開發，直到最後的聯調。
通過對比，我們發現前端搭建mock資料服務的方式無疑是前端開發的首選。 但是，對於傳統的前端mock服務，我們做的僅僅只有，前端頁面發起請求，mock服務接收請求，根據請求路徑尋找對應的mock檔案，最後返回給前端。 相信大多公司也是這麼幹的。
那它有什麼不足呢？
考慮一下以下場景：
如果我們想要返回不同的mock資料，開發者不得不手動的修改mock資料來源檔案，每次註釋，解註釋。
狀態少還可以，比如一個介面，成功或失敗，在介面的顯示需要不同，因此，我們就需要寫完兩組模擬資料，並註釋一組比如失敗，等到需要用失敗的時候，解註釋失敗，註釋成功。
如果狀態多呢？比如一個使用者資訊介面，使用者分為企業使用者和個人使用者，然後，企業使用者有四種狀態：未實名、實名中、已實名、實名失敗。預設模擬資料為企業使用者->已實名，這個時候，我們想要測測所有的情況，那就得做7次註釋加解註釋的操作。
版本迭代了，已實名還有分：初級會員、中級會員、高階會員、超級會員。我們以後每次改相關程式碼，為了避免出bug被測試看不起，就不得不所有的情況全都再測一遍。
如果狀態更多呢？
有同學說，我三年的註釋解註釋工作經驗，怕這百把十個操作？我就喜歡每次改完程式碼就一頓註釋解註釋操作，讓老闆看到，我工作是有多麼飽和。
我相信有些很有毅力的同學，會覺得這都不是事兒。但是，這麼做的話，我們能保證我們不會漏掉任何一個有多個狀態的介面嗎？
又有同學說：恩，這個不難，在每個有多個狀態的mock檔案中加個標記，比如本王宇宙最牛逼這行註釋，然後全域性搜尋，就能知道哪些mock檔案會有多狀態了。
那我們能保證我們不會把狀態拼接錯亂嗎？比如，明明是個人使用者，卻不小心解註釋了企業使用者的某些狀態。 有同學說：小意思，寫註釋就好，想要多少寫多少，下次一行行看註釋就好了，吐了算我輸。 恩~~~對於這樣的槓精，我只能說：
迴歸正題，為了解決這些問題，koa-mock-switch誕生了。
How
那麼，怎麼設計koa-mock-switch這個server呢？
首先，先說一下我們的期望，我們期望：
1、有一個涉及多狀態mock資料的管理頁面，方便檢視
2、通過UI介面的操作就可以控制返回對應狀態的mock資料
其實這個方案並不是我首創的，最開始接觸這個方案，是從我們部門同事那，原始版叫做mock-middleware。我先解釋一下他的實現原理。
前端專案browser -> node 演算法：
其實就是在express或者koa的node服務中，維護一個全域性變數，我們叫$config，資料型別為物件，key為api的地址，value為返回的模擬資料。如果node端接收到瀏覽器的請求的話，先在$config中查詢，看看是否存在當前api，有的話直接返回，沒有的話，就尋找對應的mock檔案，返回資料。同時，將api作為key，返回資料作為value存入$config。
mock管理介面browser -> node 演算法：
為了達到通過UI介面的操作就可以控制返回對應狀態的mock資料的效果，會有一個和專案無關的，專門用來管理mock返回資料的頁面，我們就叫做mock-management-page吧，如圖：
這個頁面的列表渲染，依賴與事先建立的mockSwitchMap。
渲染完以後，只要切換狀態，就會想node服務發起ajax請求，引數為api的地址以及對應的status（如成功或失敗）。node端接收到後，讀取該api的mock檔案，根據需要的狀態，更新$config。
如此一來，我們就可以通過mock-management-page，在開發的時候，簡單的點選一下按鈕，就達到了切換返回資料的目的。
然而，還是會遇到問題，從演算法可以看出，mock-management-page可以發起ajax對應的status是單一的，會遇到什麼問題呢？
缺點很明顯：
1、不得在每次的返回函式中，根據key（即之前說的各種狀態）進行人工處理。
2、我們看到有段註釋// 'bankCardType': 'ENTERPRISE',，我們依然用了傳統的註釋，解註釋方式來切換返回資料。因為，我們之前說過mock-management-page可以發起ajax對應的status是單一的。如果我們一定要把它變為可切換方式，我們不得不這麼寫：
我們發現，處理狀態的過程又多了，最終導致該介面狀態越多，處理邏輯約繁重，想想都覺得好心疼，做了這麼多，回報卻不是很大。
但是，細心的同學可以發現，我們根據key（即之前說的各種狀態）的名字規定，可以做些不同的處理，所以是不是存在某種方式，可以通過一個通用的資料處理方法，自動地根據key（即之前說的各種狀態）的規則，處理後得到最終理想的資料呢？
當然可以！最後，我們的任務就是：制定key規則；編寫一個通用資料處理函式。
Rule
我們通過事先約定來規定mockSwitchMap的value，為了便於理解，我們回到Hello Kitty的例子，我們重新構造mockSwitchMap的value：
我們[]代表資料的層級，用@代表狀態，@作為狀態選項，經過處理以後，會向上提升一層。
/api/kitty的mock資料檔案：
如此，我們就可以非常靈活地管理我們想要返回的mock資料，並且，對於哪些mock介面具有多種狀態一目瞭然。此外，如果不需要多狀態的mock資料和傳統mock檔案一樣，不需要做任何額外的處理，比如Tom的mock檔案：
npm安裝
npm install -D koa-mock-switch
複製程式碼node端使用方法
const path = require('path')
// mock檔案的根目錄
const mockRoot = path.join(__dirname, './mock')
// require koa-mock-switch
const KoaMockSwitch = require('koa-mock-switch')
// mock管理列表
const mockSwitchMap = require('./mockSwitchMap.js')
/**
* KoaMockSwitch(mockRoot, mockSwitchMap, apiSuffix)
* @param mockRoot mock檔案的根目錄
* @param mockSwitchMap mock管理列表
* @param apiSuffix 客戶端請求api的字尾，比如'/api/kitty.json'，apiSuffix就是'.json'
*/
const mock = new KoaMockSwitch(mockRoot, mockSwitchMap, '.htm')
// 啟動mock服務
mock.start(7878)
複製程式碼還是對使用方法疑惑的同學，可以參考demo。
專案地址demo
專案中有demo演示，同學們可以自己clone後體驗下。 地址：koa-mock-switch
demo啟動
安裝
npm install
複製程式碼第一個視窗shell
npm run mock
複製程式碼第二個視窗shell
npm run demo
複製程式碼