koa-mock-swich

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呢？ 首先，先说一下咱们的指望，咱们指望：

一、有一个涉及多状态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
复制代码