题目有点大，下面简略说下要处理的问题以及对应的处理计划思路。
问题
mock也是前端工程化的一部分，所以正常来讲每个前端项目都会有各自mock 的完成。
一般前端完成mock，有不限于以下几种形式：
- 手写假数据，接口恳求直接回来写好的假数据；
-
mock.js阻拦接口，并回来对应编写好的mock； -
easymock、yapi等渠道接收； -
Json-server阻拦+faker生成mock； - ……
以上办法各有优缺点，场景不同，需求也纷歧样，存在即合理，不必强分好坏。
但依据个人调研运用，无论运用哪一种，都免不了比如以下：
- 接口、参数的复制粘贴
- mock数据大多只支持查询
等通用性问题，当然也或许是因为运用不够深入的原因。所以依据这些问题，就想着能不能把这种通用性问题经过东西去处理呢？
所以就有了本篇内容的实践。
完成进程
大概捋一下思路：
-
swagger-json生成接口、装备信息； -
json-server接收并处理对应恳求； -
faker依据1的接口装备信息，处理mock数据； - 整合
2和3进程，校验mock的增修正查功用； - 客户端校验；
看进程可知，和一般mock办法纷歧的，中心是多了第一个进程，动态生成全系统接口及相关收支参装备信息，以及多种办法的整合处理。
进程工作量会比较大，完成进程也纷歧定相同，但原理是一样的，所以本篇内容偏理论，下面仅评论完成原理。
1. 接口装备
完成接口mock的进程，一般这部分工作的重复量是最大的，便是手动的复制接口及收支参，然后针对的处理mock。
所以依据这种状况，之前完成了经过类似swagger等渠道，一键获取接口及收支参装备的功用。
可看 swagger-json 经过swagger接口快速生成AntDesign组件装备。
简略讲下swagger-json的完成原理：
- 依据后端提供的swagger-ui地址，获取烘托swagger-ui的接口；
- node环境恳求接口，解析对应的接口及收支参数据结构；
- 按需组装收支参，生成对应需求的收支参装备；
- 生成对应json文件，便利一键取用，很多减少一个个复制粘贴的工作；
完成进程的重点是swagger接口的数据解析，以及按需数据的组装，剩余的便是文件的读写。
完成之后根本随处可用，依据不同需求，改改收支口模型就行，收益比例比较高。
贴一个生成的简略比如
/**
接口：get-people-list
生成文件：get-people-list.json
生成装备如下：
*/
{
"query": [
{
"key": "name",
"label": "查询人",
"children": []
},
{
"key": "age",
"label": "查询年龄",
"children": []
},
{
"key": "tel",
"label": "查询电话",
"children": []
}
],
"params": [
{
"key": "name",
"label": "名字",
"children": []
},
{
"key": "age",
"label": "年龄",
"children": []
}
]
}
依据上面的json，可以很便利的接入如Antd的表单及table等组件的config部分，省去手动装备的进程。
2. 恳求接收
上面生成了对应的接口及装备，接下来处理恳求接收的部分。
mock.js等也可以接收恳求，但运用json-server更好的当地，在于json-server完成并增强了db、server的处理，根本到达仿真db的才能。
下面是处理进程：
-
依据json-server读写规矩，同步、修正上面生成的接口及装备；
依据接口的特性，恳求途径及req、res等一般都需求做rewrite才能满意需求，而json-server的匹配规矩个人感觉有点绕且不是很明晰。
但这部分是恳求接收的中心，不能省掉。
因为是一次性处理整个对接系统的接口，所以接口越多工作量和复杂度相对也越大一些。
贴个简略的rewriter比如：
{ //重写 /app/途径 "/app/*": "/", // post恳求接口 /get/list/1，json-server实践会对文件get-list.json建议get-list且id为1的恳求，最终回来id=1的数据 "POST/get/:people/:id": "GET/app-:people/:id", }规矩比较简略，所以也只满意了根本需求。
-
发动server，接口调试；
参考上面的接入，可以拿几个简略的接口，做下匹配及转译，然后发动server，先做查询、新增的调试，成功之后完成批量操作。
参考 simple-example。
-
整合接口list，json监听；
单个接口调试完成了增修正查流程，根本规矩也就摸的差不多清楚，接下来整合接口。
需求整合的原因是当json文件过多的时分，json-server监听无法到达预期，原因也没有深究，所以干脆做了整合，只监听一个文件。
这个时分假如想调试很多的接口，就需求不断复制粘贴相关接口及收支参，效率极端低下，这时分就表现了上面
swagger-json完成的好处了。下面简略看下完成后的贴图
-
按需调试，磨平差异
接口量大，纷歧定每个接口的状况都能兼顾到，这个时分需求依据不同状况，做不同的接口rewrite及req、res的阻拦转化处理。
其实假如后端接口完成满意标准，前面
1~3根本能满意需求，但现实总是不能如人意，所以这步往往没法省掉。json-server也考虑到这点，提供了不同状况的处理，下面是部分规矩截图
-
拓宽处理
假设
json-server仍然无法满意对阻拦处理的需求，可以考虑手动接入更符合日常运用的express等作拓宽处理。
3. faker数据
前面调通了json-server的阻拦，简略完成了接口对应的增修正查功用，但对查询而言，往往需求很多数据的mock。
对很多数据的生成，这儿用的是faker-js+lodash完成。
原理便是lodash担任化量，faker担任生成。
下面贴个简略demo：
import { faker } from "@faker-js/faker"
import { times } from "lodash-es"
// db数据faker
export function fakerDb (params /** 出参 */ = {}, length/** mock数据长度 */ = 20) {
const mock = times(length, function (n) {
const obj = {}
const keys = Object.keys(params)
for (const key of keys) {
obj[key] = faker.name.fullName()
}
return {
...obj,
id: n + 1
}
})
return mock
}
再结合上面的接口接收及整合，就可以生成仿真mock。
下面看下整合后每个接口faker20条数据的mock状况
4. 客户端校验
上面其实已经根本完成了mock渠道的功用，接下来便是在dev等环境完成接口的实在mock。
和常规流程一样：
- 发动上面
mock-server，比如发动后地址是localhost:3000; - 实在恳求把
proxy及baseUrl换成mock的地址及对应装备； - 建议恳求；
下面看下实在环境的演示进程：
-
建议恳求
// Get默认是查询功用，Post是新增 axios.get("http://localhost:3000/app/matter/detail").then(res => { console.log('Mock：', res); }) axios.post("http://localhost:3000/app/matter/detail").then(res => { console.log('Mock：', res); }) -
控制台验证
-
mock文件验证
可以看到chrome控制台及本地接口整合并接入faker后的mock/index.json都生成了对应数据，这也是运用faker替代mockjs的原因，可以更实在的反应fake-db状况。
总结
上面仅仅讲了完成的根本原理及进程，具体完成进程的工作量仍是相对大一些，也就不再细述，下面再次总结下进程：
- 经过swagger接口获取组装并生成接口装备的json文件；
- json-server阻拦恳求做转发处理；
- faker生成db数据；
- 建议proxy恳求验证；
仍是上面的话，前端mock有多种多样的完成计划，这儿也仅仅针对自身状况，对已有的功用做整合，但不论如何完成，需求其实都是一致的。
这个最终的需求便是赋能增效，这也是程序员工作自身永久的主旋律，只要能更好的完成需求，办法自身也仅仅某个阶段的某个恰好的办法罢了。
所以程序员完成需求仅仅根本要求，可以更好的、创新性的完成，才是推进技术发展的重要才能。
