前言针对目前前端mockdataserver的不足，继承同事的思想，做了一个简单易用的基于koa的前端-Mina-san的模拟工具——koa-mock-swich。What这是一个在前端模拟数据并管理返回数据的服务器。为什么需要koa-mock-switch。目前开发过程中的mock数据方式主要分为：1.后端mock数据，即在本地环境中有一个模拟数据的数据库，然后，开发好后端接口后，和在线一样进行增删改查，最后返回给前端数据。缺点：时间上，当前端需要数据接口时，需要等后端开发好接口，才能进行下一步的开发。从职责上来说，即使前端开发页面效率很高，但是因为最终完成时间肯定是在后端之后，如果一个项目的进度被耽误了，前端就会受到指责。2、前端搭建mock数据服务我们的前端通常使用express或者koa搭建自己本地的前端mock数据服务。市面上也有很多现成的npm可以使用。优点：前后端并行开发。前后端只需要在开发前一起定义接口规范即可。之后前端根据api文档模拟mock数据，你可以躲在小黑屋独自开发，直到最后联调。通过对比，我们发现搭建mock数据服务的前端方式无疑是前端开发的首选。而对于传统的前端mock服务，我们所做的只是，前端页面发起请求，mock服务接收请求，根据请求路径找到对应的mock文件，最后返回给前端。我相信大多数公司都是这样做的。那么它有什么问题呢？考虑以下场景：如果我们要返回不同的模拟数据，开发人员必须手动修改模拟数据源文件，每次注释和取消注释。如果状态很少也没关系。比如一个界面，成功或者失败，需要在界面上有不同的显示。因此，我们需要编写两组仿真数据，并标注一组如故障。当需要失败时，解释注解的失败。注释成功。如果有很多状态怎么办？例如，在用户信息界面中，用户分为企业用户和个人用户。然后，企业用户有四种状态：未实现、实名、已验证、实名失败。默认模拟数据为企业用户->实名。这时候如果我们要测试所有的情况，就得做添加评论和评论这7个操作。版本已迭代，实名有分：初级会员、中级会员、高级会员、超级会员。以后我们每次修改相关代码，为了避免bug被测试看不起，都得把所有的情况都测试一遍。如果有更多的州呢？有同学说，以我三年的标注和解释经验，怕是要上百次操作吧？每次改代码我都喜欢注释和取消注释，这样老板就可以看出我的工作有多饱和。相信有些有毅力的同学会认为这不是问题。但是，通过这样做，我们是否可以保证我们不会错过任何具有多个状态的接口？另一个同学说：嗯，这个不难。给每个mock文件加一个标记，有多个状态，比如全宇宙最厉害台词的评论，然后全局搜索，知道哪些mock文件的状态比较多。地位。那能不能保证不会把state的拼接搞乱呢？比如明明是个人用户，却无意中解读出了企业用户的某些状态。有同学说：小事一桩，写笔记就可以了，想写多少就写多少，下次再一行行看笔记，吐了我就输了。嗯~~~对于这样的高手，我只能说：言归正传，为了解决这些问题，koa-mock-switch诞生了。那么，如何设计koa-mock-switch服务器呢？首先，让我们谈谈我们的期望。我们期望：1.有一个涉及多态mock数据的管理页面，方便查看。2.可以通过UI界面的操作来控制返回相应状态的mock数据。事实上，这个解决方案并不是我的第一个。是的，最先接触这个解决方案的是我们部门的同事。原始版本称为模拟中间件。先解释一下他的实现原理。前端项目浏览器->节点算法：其实在express或者koa的节点服务中，维护了一个全局变量。我们称之为$config，数据类型是object，key是api的地址，value是返回的模拟数据。如果node端收到浏览器的请求，首先在$config中查找是否有当前的api，有则直接返回，没有则找到对应的mock文件返回数据。同时以api为key，将返回的数据作为value存储在$config中。Mock管理界面browser->nodealgorithm：为了通过UI界面的操作达到控制相应状态下mock数据返回的效果，会出现一个与项目无关的页面，专门用于管理模拟的返回数据。我们称之为mock-management-page，如图：这个页面的列表渲染依赖于提前创建的mockSwitchMap。渲染完成后，只要切换状态，就会向节点服务发送ajax请求，参数为api的地址和对应的状态（如成功或失败）。节点收到后，读取API的mock文件，根据需要的状态更新$config。这样我们在开发的时候就可以使用mock-management-page来达到切换和返回数据的目的，只需点击一个按钮即可。从算法可以看出，mock-management-page可以发起ajax，对应状态为single。会遇到什么问题？缺点很明显：1.没有在每个返回函数中根据key（也就是上面说的各种状态）进行人工处理。2、我们看到一个注释//'bankCardType':'ENTERPRISE'，我们还是用传统的注释和取消注释的方式来切换返回的数据。因为，我们之前说过mock-management-page可以发起ajax，对应的状态是single。如果一定要让它可以切换，就得这样写：我们发现处理状态的进程比较多，最终导致界面的状态比较多，处理逻辑也比较繁琐。这么多，但是回报并不大。不过细心的同学可以发现，我们可以根据key的名称（也就是前面说的各种状态）做不同的处理，那么有没有办法自动使用通用的数据处理方式呢？根据key的规则（也就是上面说的各种状态），经过处理后最终的理想数据呢？当然！最后，我们的任务是：制定关键规则；编写一个通用的数据处理函数。规则我们通过事先约定来规定mockSwitchMap的值。为了便于理解，让我们回到HelloKitty的例子。我们重构mockSwitchMap的值：我们用[]表示数据层级，用@表示状态，@作为状态选项，经过处理以后，会上一层。/api/kitty的mock数据文件：这样我们就可以非常灵活的管理我们想要返回的mock数据，而且哪些mock接口有多种状态一目了然。另外，如果不需要像传统mock文件那样的多态mock数据，则不需要做额外的处理，比如Tom的mock文件：npminstallnpminstall-Dkoa-mock-switchnodeusemethodconstpath=require('path')//mock文件的根目录constmockRoot=path.join(__dirname,'./mock')//requirekoa-mock-switchconstKoaMockSwitch=require('koa-mock-switch')//mock管理列表constmockSwitchMap=require('./mockSwitchMap.js')/***KoaMockSwitch(mockRoot,mockSwitchMap,apiSuffix)*@parammockRootmock文件根目录*@parammockSwitchMapmock管理列表*@paramapiSuffix客户端请求api后缀，比如'/api/kitty.json'，apiSuffix为'.json'*/constmock=newKoaMockSwitch(mockRoot,mockSwitchMap,'.htm')//启动mockservicemock.start(7878)或者使用方法有疑问的同学可以参考demo。项目地址demo项目中有demo演示，同学们可以自己克隆后体验。地址：koa-mock-switchdemo开始安装npminstallfirstwindowshellnpmrunmocksecondwindowshellnpmrundemo
