前端mock數據server新概念 — 狀態管理

前言

針對目前前端mock數據server的不足，本王繼承在同事的思想之上，爲米娜桑作了一個簡單易用的基於koa的前端mock工具 —— koa-mock-swich。

What

這是一個前端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呢？
首先，先說一下咱們的指望，咱們指望：

一、有一個涉及多狀態mock數據的管理頁面，方便查看

二、經過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是單一的，會遇到什麼問題呢？

缺點很明顯：

一、不得在每次的返回函數中，根據key（即以前說的各類狀態）進行人工處理。

二、咱們看到有段註釋// '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