题目有点大，下面简略说下要处理的问题以及对应的处理计划思路。

问题

mock也是前端工程化的一部分，所以正常来讲每个前端项目都会有各自mock 的完成。

一般前端完成mock，有不限于以下几种形式：

  • 手写假数据，接口恳求直接回来写好的假数据；
  • mock.js阻拦接口，并回来对应编写好的mock；
  • easymock、yapi等渠道接收；
  • Json-server阻拦+faker生成mock；
  • ……

以上办法各有优缺点，场景不同，需求也纷歧样，存在即合理，不必强分好坏。

但依据个人调研运用，无论运用哪一种，都免不了比如以下：

  • 接口、参数的复制粘贴
  • mock数据大多只支持查询

等通用性问题，当然也或许是因为运用不够深入的原因。所以依据这些问题，就想着能不能把这种通用性问题经过东西去处理呢？

所以就有了本篇内容的实践。

完成进程

大概捋一下思路：

  1. swagger-json生成接口、装备信息；
  2. json-server接收并处理对应恳求；
  3. faker依据1的接口装备信息，处理mock数据；
  4. 整合2和3进程，校验mock的增修正查功用；
  5. 客户端校验；

看进程可知，和一般mock办法纷歧的，中心是多了第一个进程，动态生成全系统接口及相关收支参装备信息，以及多种办法的整合处理。

进程工作量会比较大，完成进程也纷歧定相同，但原理是一样的，所以本篇内容偏理论，下面仅评论完成原理。

1. 接口装备

完成接口mock的进程，一般这部分工作的重复量是最大的，便是手动的复制接口及收支参，然后针对的处理mock。

所以依据这种状况，之前完成了经过类似swagger等渠道，一键获取接口及收支参装备的功用。

可看 swagger-json 经过swagger接口快速生成AntDesign组件装备。

简略讲下swagger-json的完成原理：

  1. 依据后端提供的swagger-ui地址，获取烘托swagger-ui的接口；
  2. node环境恳求接口，解析对应的接口及收支参数据结构；
  3. 按需组装收支参，生成对应需求的收支参装备；
  4. 生成对应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的才能。

下面是处理进程：

  1. 依据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",
}

    规矩比较简略，所以也只满意了根本需求。

  2. 发动server，接口调试；

    参考上面的接入，可以拿几个简略的接口，做下匹配及转译，然后发动server，先做查询、新增的调试，成功之后完成批量操作。

    参考 simple-example。

  3. 整合接口list，json监听；

    单个接口调试完成了增修正查流程，根本规矩也就摸的差不多清楚，接下来整合接口。

    需求整合的原因是当json文件过多的时分，json-server监听无法到达预期，原因也没有深究，所以干脆做了整合，只监听一个文件。

    这个时分假如想调试很多的接口，就需求不断复制粘贴相关接口及收支参，效率极端低下，这时分就表现了上面swagger-json完成的好处了。

    下面简略看下完成后的贴图

全系统接口一键mock实践

  1. 按需调试，磨平差异

    接口量大，纷歧定每个接口的状况都能兼顾到，这个时分需求依据不同状况，做不同的接口rewrite及req、res的阻拦转化处理。

    其实假如后端接口完成满意标准，前面1~3根本能满意需求，但现实总是不能如人意，所以这步往往没法省掉。

    json-server也考虑到这点，提供了不同状况的处理，下面是部分规矩截图

    全系统接口一键mock实践

  2. 拓宽处理

    假设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状况

全系统接口一键mock实践

4. 客户端校验

上面其实已经根本完成了mock渠道的功用，接下来便是在dev等环境完成接口的实在mock。

和常规流程一样：

  1. 发动上面mock-server，比如发动后地址是localhost:3000;
  2. 实在恳求把proxy及baseUrl换成mock的地址及对应装备；
  3. 建议恳求；

下面看下实在环境的演示进程：

  1. 建议恳求

    // 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);
})

  2. 控制台验证

    全系统接口一键mock实践

  3. mock文件验证

    全系统接口一键mock实践

    可以看到chrome控制台及本地接口整合并接入faker后的mock/index.json都生成了对应数据，这也是运用faker替代mockjs的原因，可以更实在的反应fake-db状况。

总结

上面仅仅讲了完成的根本原理及进程，具体完成进程的工作量仍是相对大一些，也就不再细述，下面再次总结下进程：

  1. 经过swagger接口获取组装并生成接口装备的json文件；
  2. json-server阻拦恳求做转发处理；
  3. faker生成db数据；
  4. 建议proxy恳求验证；

仍是上面的话，前端mock有多种多样的完成计划，这儿也仅仅针对自身状况，对已有的功用做整合，但不论如何完成，需求其实都是一致的。

这个最终的需求便是赋能增效，这也是程序员工作自身永久的主旋律，只要能更好的完成需求，办法自身也仅仅某个阶段的某个恰好的办法罢了。

所以程序员完成需求仅仅根本要求，可以更好的、创新性的完成，才是推进技术发展的重要才能。