1, 导读

1.1, 你会看到什么?
- 个人对mock的理解和应用场景.
- 根据自己的实际工作项目,手摸手教你进行详细的mockjs部署说明,而不是网上千篇一律照搬官网的简单实例.看完之后直接就可以在自己的项目中进行使用,满足正常的工作项目需求.
- 这种学法与通过node的dev-server实现MockServer的优缺点.
- 这种写法的适用场景.
- 最后说明下我的开发环境是vue2+elementUI2+nginx.
1.2, 你不会看到什么?
- 你将不会看到对mock语法的逐个解说,这个官方文档已经详细说明了.如果你对用法还是有很多疑点,那就在项目里自己动手敲代码,去实践!其实这样比你在度娘和Google中搜索要快得多,还印象更深!
- 你将不会看到相关的mock框架的使用说明,例如json-server,easy-mock(这个还是很好用的!)等.

2, mockjs功能及适用场景

2.1, mockjs的功能
- 生产数据:通过mockjs提供的方法,你可以轻松地创造大量随机的文本,数字,布尔值,日期,邮箱,链接,图片,颜色等.
- 强大的拦截功能:mockjs可以进行强大的ajax拦截.能判断请求类型,获取到url,请求参数等.然后可以返回mock的假数据,或者你自己编好的json文件.功能强大易上手.
2.2, mockjs适用场景
- 前后端分离:由于mockjs,前端的数据请求可以自给自足, "独立" 于后端开发.在项目前期,前端可以专心于自己的前端展示,后端可以专心于自己后端的接口和数据处理.但前后端分离最怕的情况就是:前端自己玩自己的,后端也自己玩自己的.等到联调时,发现接口完全牛头不对马嘴! 所以在开发时,前后端也要时刻保持沟通,及时确认最新的接口和数据结构. 这里推荐使用swagger进行管理.
- 方便单元测试:由于mockjs能产生很多随机数据,模拟很多请求场景.所以可以保证单测一部分的真实性.但个人感觉还是不能完全替代真实的调用后端接口,后端处理的情况更加复杂.

3, mockjs项目实践

3.1, 安装mockjs

npm install mockjs --save-dev

检查mockjs是否安装成功可以在package.json和package-lock.json中搜索mockjs是否存在.

3.2, 创建mock文件夹结构

因为实际项目需要mock的模块比较多,并且涉及到多人开发.所以我这里采用了如图所示的文件夹结构,这样每个人可以根据自己所负责的模块分别存放mock数据.条理更加清晰,最重要的是数据不会混淆.如果你只需要mock几个接口的数据,并且涉及到的开发人员较少,则可以完全使用官网教程上的,全部写在一个mock.js上.

各个文件说明:

mock:存放所有mock相关的文件,建议放在根目录,方便获取和查看.

test:按项目模块分类存放对应的mock文件.例如:device存放是device设备模块需要的mock文件.这里test为存放这次演示所需的mock文件.

test-mock.js:mock主文件.主要是mock数据,对拦截请求做处理.

test-json.json:存放json格式的假数据.

index.js:后面在main.js中引入的文件.作用就是将所有模块的mock.js进行引入.

utils.js:根据项目需求,将常用的模拟数据方法写在里面.方便模块mock假数据.

3.3, test-json.json的说明.

在定义接口阶段,后端给出的接口文档里就会有请求的接口和返回数据实例.这个时候虽然接口还不能访问,但有了mockjs后,我们前端已经可以进行ajax请求.并且在json文件中.将接口文档里的数据实例,复制粘贴,然后改一下就完成了最原始最简单的数据实现.但如果是数据有特殊要求,数量很多,结构很复杂的,建议还是使用mockjs给出的方法来造数据.

这里安利一下swagger,上图截自swagger.这个时候你只需将ExampleValue下的数据实例进行复制.然后粘贴到json文件中,然后稍微修改一下就完成了.这里我就不写出来了,占地方.其实在模拟简单数据时,完全可以使用这种方法,没必要使用mock的方法.

3.4, test-mock.js的说明(重点)

import Mock from 'mockjs' //引入mock 
import testJson from './test-json.json' //引入上面创建的json假数据 
import utils from '../utils' //引入公用方法   
const res =function (opt) {
  //opt为ajax请求的选项集.包含url,type和body三个属性
  // opt.url为请求的url.
 //opt.type为请求类型,例如get,post,delete
 //opt.body为请求的参数   
 
//1, 使用mock方法来造数据
  let mockData =Mock.mock({
  'code':0,
  'msg':'成功',
  'list|1-10':[{
  'id|+1':1
  }]
 });  
 let data=JSON.stringify(mockData,null,4);//将数据进行转换    

//2, 对请求参数进行判断
  let param=opt.body;//用param保存请求的参数
  let result; //用result保存对param校验的结果    

//... 省略对param进行校验的过程    

//3, 根据校验的结果返回数据
  if(result===true){
  //此时校验结果正确
  return data;
  //return testJson 也可以返回之前写好的json文件.自己看情况选择.数据不复杂情况下,我是直接返回.json文件.
  }else {
   return {
  //校验错误,则返回错误提示信息
     'msg':'请求参数错误'
  }
 } 
}   

Mock.mock(/devicemanage\/api\/pc\/dm\/device\/structure\/query\?token=/,'post',res)
//这里使用mock()的函数写法.这样就可以获取到请求的参数,这里url是正则的写法.
//Mock.mock(rul,rtype,function(opt))  
//rul:需要拦截的url.这里有两种写法,一种是字符串形式,例如:'/api/device'则表示只能拦截/api/device请求.但我们可能会经常需要在url上添加token等其他参数.
//这时就需要写成第二种形式,正则表达式/api\/device/,这样我们就能拦截所有包含/api/device的请求.这样我们在进行ajax请求时,就可以直接编写真实的url地址.
//rtype:表示需要拦截的ajax请求类型.例如:get,post,put,delete等.
//function(opt):响应数据的函数,其中opt已经在代码最上面进行了说明.

3.5, index.js的说明

import device from './device/device-mock' 
import event from './event/event-mock' 
import home from './home/home-mock' 
import log from './log/log-mock' 
import patrol from './patrol/patrol-mock' 
import test from './test/test-mock'

从上面的代码来看,这个文件的作用很显然,就是将分散的mock文件集合起来.后面再添加新的mock文件,都需要在这里引入.

3.6, utils.js的说明

这个js文件,就是存放你需要用到的公用方法(例如json格式转换)和项目常用的mock数据(例如我司常用的设备列表和组织结构).这里我就不贴自己公司代码了.自己根据官方文档mock常用的数据并导出.

3.7, 在main.js中引入的说明

import mock from '../mock/index'

在main.js中引入也很简单.只需要引入上面的写好的index.js就可以了.到此你就已经完成了mockjs的项目实践.赶紧跑一遍看看!

4, 为什么我没用自带的dev-server搭建Mock Server?

一句话概括就是暂时不适合该项目.下面列出几条主要原因,仅代表个人观点和在该项目情况下.如果你觉得有其他看法或者更好的建议和想法,欢迎评论指正.

直接使用mockjs项目结构修改更少,语法书写也更简单.网上很多教程都是通过在dev-server上进行修改.然后通过proxyTable或者利用before钩子进行拦截.但是我感觉还是很复杂,结构也不明显,并且需要对express的语法和用法要有比较充分的了解,否则修改起来很容易报错,也不是很安全.
当你修改了mockjs后,网页会自动刷新,看到你mock的数据.如果你是在dev-server上修改的话,则需要重新跑一边run dev.虽然你可以装插件,不用手动dev.但效率和方便程度上还是比不上自动刷新的.
请求拦截方面,mockjs优先级最高.mockjs>nginx>dev-server.所以你可以使用Mock.mock()方法拦截任何你想拦截的请求而不需要担心nginx或者其他代理.而当你使用dev-server进行拦截时,并且你也和我一样,项目之前配置了nginx,则会比较麻烦.可能你还需要对nginx进行配置,避免拦截了dev-server的请求.然后重启一遍服务,然后再run dev.后端接口完成后,你还得再改回去.(举个栗子:nginx拦截了/devices,但这次新增了一个接口路径/devices/newApi你需要在dev-server上拦截.这时你就必须修改nginx的配置.)
mockjs提供的mock()方法,可以更简单方便的限制请求类型并获取请求参数.并以此返回对应的数据.并且还可以按自己喜好返回.json文件或者是mock的数据.
这种文件结构其实也可以做到mock文件的模块化管理,实现也不复杂.没必要借助dev-server进行模块化.

这种写法的缺点:

由于mockjs是js层面,最先开始拦截.所以有时要注意不要和之前配置的代理冲突了.
由于mockjs是完全立足于前端,所以如果后端接口变了的话,需要自己及时手动进行修改.

5, 适用场景

5.1 适合:

如果前端开发人员不多,只有四五个人.并且不存在跨地区合作的话.其实这种写法已经可以满足现阶段mock需求.

5.1 不适合:

如果前端开发人员很多,存在跨地区合作,交流困难,后端接口需要频繁修改的话.这种写法并不适合!这时候推荐使用easy-mock.部署到本地内网后,就可以和其他前端后端小伙伴愉快地共同维护mock数据和接口.