请求不存 vuex 的数据这样写,感觉多此一举啊,贼鸡儿不好维护。单独开个 API 文件写接口不更好吗? - 知乎提问

目前我认为这种做法确实是多此一举。

vue 组件首先作为组件来说应当满足高内聚,低耦合。

每个组件涉及的 api 每个组件自己负责,每个组件相关的资源用文件夹包裹

对于开发者来说,请求个数据还要各种切换文件夹,定义各种范式,徒增负担。最费解的是很多项目上了这种设计,却并没有用到 vuex 最基本的数据共享功能,请求缓存就更谈不上了,再完成了一系列复制粘贴之后,各个页面还是 action 直接干,何苦呢?

究其原因,其实还是在设计的时候并没有想清楚设计和项目以及团队成员的匹配度,没有完善的文档,也没有最佳实践,就想着让维护者自觉去感悟,不太现实。业务忙起来的结果,就是把你的那一套重新当成 ajax 来用而已!

既然如此,何不就好好设计一下你的 ajax 模块呢?

接上面再聊聊,两种管理思想,大一统或分而治之。

有的人喜欢按照资源来划分工程,比如早期网站的项目结构基本都是:/img,/script,/css;有的喜欢按照资源关系来划分工程:/component-xx/index.js,/component-xx/style.css

再多说一点,怎么去组织文件,其实也一定程度上反映了人的组织原则

比如,一般觉得不应该把 api 请求抽出去的人,其实遵循的是短路原则,即尽可能做少的事情,真正到了需要多做的时候再多做。拿代码风格来说,比如我

1
2
3
4
5
6
7
8
9
10
11
12
// 可以不写大括号就不写
if (true) run(1)
else {
run(2)
run(3)
}

// 如果父层可以表意,子属性绝不自报家门
const user = {
// userName: 'Jack'
name: 'Jack',
}

还有比如我实现的前端校验插件,都会默认去校验输入框不能为空,而不是每个输入框都要显式设置 required,因为显然不能为空的情况会更多,能少写就少写

还有 element-ui-verify#alias 这个 api 的设计也是基于这种理念

总之,学会渐进地升级你的项目,不要上来就有过重的设计,前端新科技新思想层出不穷,船小好调头!


 评论