原文地址: [轻量JS Mock对象生成工具-Mocker] (http://blog.23lab.com/2017/05/23/%E8%BD%BB%E9%87%8F%E9%9A%8F%E6%9C%BAJS%E5%AF%B9%E8%B1%A1%E7%94%9F%E6%88%90%E5%B7%A5%E5%85%B7-Mocker/)
背景
前端开发过程中, 通常的开发流是, 前后端定义协议, 再分别开发. 然而此开发流必然存在前后端并行的阶段, 通常情况此阶段前端不得不自己手写假数据先开发界面和交互逻辑, 等到和后台联调, 再把假数据替换成真实的后台数据. 这整个过程造假数据的过程非常重复, 开发体验糟糕. 我尝试搜索解决此问题的反感, 总结下来基本是两个思路:
- 直接生成mock的后端服务, 根据指定的协议(例如swagger)自动生成后端mocker, 例如 swaggerhub
- 前端生成mock数据直接返回, 例如 Facker.js和MockJS
不过我尝试了上述两种方式以后并不是很满意.
第一种我遇到的问题是: 因为内网的各种限制, 我并不能很顺畅的访问到它mocker的服务, 当然, 是有一些替代的私有化部署方案, 但是算下来工作量其实也不小, 而且明显感觉一件简单的事情变得越来越复杂.
因为第一种方式遇到的问题, 我也更偏向于使用第二种方案, Faker.js可以说是大而全, 能满足所有需求, 但是也正是因为大而全, 我抛弃了他, 因为我理解这种Mock的需求, 虽然是开发前期的刚需, 但是频率通常不会很高, 算是低频刚需. 如果用一个大而全的, 因为API复杂, 会导致我用一次, 下次再使用的时候已经忘记了一些配置的说明, 每次用起来都要重新查, 这是比较痛苦的, 所以我希望能有一个简单一点的解决方案.
mock.js的API就明显简单很多, 然而我没有使用mock.js的原因是: 它需要mock的对象的key和值的格式说明放到一起, 例如, stringValue|1-10, 因为我需要在其他也需要公用配置, 而且我自己认为这是对Key的一种污染, 所以我更偏向于保持stringValue这个key的纯净.
正因为上述遇到的问题我才考虑自己实现一个更简单满足自己需求的Mock工具, 简单命名其为Mocker.
Mocker的目标
上面已经说了目前一些解决方案不是很满足我自己需求, 所以我准备自己开发一个, 开发之前大概思考了一下自己的需求, 主要有下面几点:
- 只支持前端mock数据, 使用时直接在前端模拟返回
- 足够简单, 类型不能太多, 只需要支持String, Number, Enum, Boolean. 并且几种类型上也只添加最基本的限制规则, 例如长度和格式.
- 支持Array和Object
根据上述目标, 最终完成了Mocker的开发并在真实项目中使用. 具体项目地址: https://github.com/UnPourTous/mocker
使用方式展示
下面是我的API配置, 其中配置了path, method, 等必要信息, 以及request/response信息, 其中response的配置遵循Mocker的规范. 例如:
import { Mocker, Types } from '@unpourtous/mocker'
const API = {
aGreatAPI: {
mockable: true,
path: 'greate/api/path',
method: 'GET',
request: {},
response: {
stringDate: Types.string('date'),
stringRange: Types.string().range(10, 100),
numberRange: Types.number().range(0, 100),
enum: Types.enum(['A', 'B', 'C'])
}
}
}
在访问此请求的时候, 通过判断mockable的设置确定是否需要返回mock数据:
class APIClient {
static get (cgi, params = {}, headers = {}, option = {}) {
if (cgi.mockable === true && cgi.response) {
// 生成mock数据
const mockResponse = Mocker.mockObject(cgi.response)
return Promise.resolve(mockResponse)
}
}
}
// 调用
APIClient.get(API.aGreatAPI).then(response => {
// 这里就可以拿到mock数据了
}, error => {
})
可以看到上面以非常简单的结构, 就可以实现前端数据的mock, 目前String支持长度限制和正则. 数字支持范围和格式. 具体API说明可以参考 https://github.com/UnPourTous/mocker
总结
Mocker因为一个低频刚需而生, 故确定他的主要特点是简单, 设计之初就希望即使允许它不能解决10%的可能场景, 也要保持简单. 所以最终API也只有10个左右, 而且非常易于理解. 当然如果您有什么建议也欢迎提PR或者联系我.
