目前应该大部分公司都采用前后端分离的方案吧,然后在开发联调和自测的过程中难免会遇到各种情况需要后端给你各种情况的数据来触发各种场景。这种时候就需要 一种可以在不影响开发并且可以让你可以得到各种所需要的数据的解决方案了~
那么目前想到的方案
方案1 直接修改字段属性
强行进入所场景这种方案在如果只是改一个字段的true或者false那么还好 但是如果在需要多个数据的修改才能触发的场景,那么修改成本大概就有点高了吧=。= 而且有可能因为忘记了而导致线上出问题
//比如 有一个三级的状态 由于需要修改stage = 2 round = 3 team = 3的情况就要在代码中这么到处修改
data(){
return {
//stage: 1,
stage: 2
...
//round: 2
round: 3,
//team: 1,
team: 3
}
}
这方法优点是够简单暴力，但是弊端也很明显 容易遗漏，在一般非请求的情况可能会用到，不过就算是非请求通过组织好代码流程也能用更好的方法解决，这里就不讨论了
方案2 在接口处写入一段假数据
这种方案好处就是只要在success处写一段假数据 就能进入需要的场景并且也不需要后端给到你需要场景的数据，只要能接口通了就可以，但是还是有一个问题 就是首先得后端先有接口=。= 按我的经验... 后端大佬一般都没这么快能给你接口 有文档已经很不错了~
axios.get('xxx').then(res => {
// this.info = res.data.info
this.info = {
nickname: '鲁路修·Vi·不列颠尼亚',
age: 18,
sex: 'gay'
}
})
还是上面的问题，因为模拟数据写了在业务代码里面了，就存在可能人为因素忘记删掉不该有的代码的问题，而且这办法也太辣鸡了点，不优雅
好了，上面两条比较简单的做法可以总结出来 数据不能在业务代码中模拟 不然很容易出现问题
那么如何在不影响业务代码的情况下 通过自己模拟数据达到前端自己实现后端数据呢~
方案3 封装请求接口 在请求处实现mock逻辑
在实现逻辑的时候，难免会有各种ajax请求或者什么请求之类的 那么如果在代码中各种请求满天飞 那不是感觉很辣鸡嘛... 那么就把所以请求的url集中起来管理，把请求头通过一个统一的变量管理起来。通过封装一个API的类来管理你的所有API，只要调用API的方法就可以实现请求了。然后既然API的类也有了，通过改造API类里面的对应url里面的方法，在对应方法里面写mock数据，就能做到不影响业务逻辑的情况下实现mock数据了~
比如
//App.vue
APIS.getUserInfo()
.done(res => {
//业务逻辑
})
.fail(err => {
//错误处理
})
//apilist.js
getUserInfo(data, params){
return this.mock({
code: 0,
data: {
xxx: 1,
bbb: 2
}
})
}
讲道理这个方法其实就是模仿我们大佬实现的api的封装方案哒~ 最近看了一下感觉好像有点jq的ajax写法的感觉哦 也不知道他是不是也是从那里拿灵感的 不知道他看到了会不会找我谈心呢 具体ajax怎么封装就不写出来了~
方案4 本地实现服务端接口返回对应数据
虽然方案3已经可以很大程度避免由于模拟数据影响业务逻辑了，但是如果有方法可以完全不影响项目代码是不是更好呢？
//server.js
const app = express();
...
app[url_data.methods](url, (req, res) => {
vailedHandle(url_data.vailed, url_data.methods === 'get'?req.query:req.body, url_data.mock(), res);
});
...
//project mock
const index = {
'xxx/getUserInfo': {
mock: () => {
return mock.mock({
code: 0,
data|1-9 :[{
'nickname|5-8': /[a-zA-Z]/,
'age|0-99': 20
}]
}),
...
}
}
}
由于最近学习了一丢丢node相关的知识哦，正好就可以练练手了~ 通过express和mockjs组合，在另外一个端口实现一个本地服务器，通过请求本地服务返回对应接口实现模拟数据，由于我们只需要接口，逻辑什么都不必管，所以只需要在mock的数据里面修改一下就能拿到需要的数据并且不必担心影响原本项目，是不是瞬间觉得高端了不少，具体api接口内容和链接 其实可以通过node爬去你们的api文档的内容自动生成，也可以通过自己封装返回请求的逻辑实现报错管理，感觉各种优化下去的话自己实现一个mock平台也好像可以哦！
总结
个人感觉方案3 和 方案4 都是很好的实践方法，而且对于代码的组织和和管理都很方便，作为专业的搬运工，在别的项目中也只需要copy一份封装好的代码改改url又是一个崭新的项目了哦~ 并且既然上一个项目已经通过qa测试那么代码肯定是安全的~可以放心服用，当然了如果有追求的话也可以把这份代码做的更加通用，用更好的方法去统一调用那就棒棒哒
嗯，当然这只是在这一年工作碰到的在联调上的问题和一些总结，因为最近听了某个live的鸡汤就想写写文章，也算是对自己知识点的一些些总结，如果有更好的方案或者有不对的地方欢迎指出来~
