Vuex 带来全新的编程体验

王豫

如果在简历上写“XX 电商系统”的实现，其实第一直觉是这个人一定是从培训班出来的。而我们“项目管理”课程正好就是做一个小型电商网站。开发时长一个月左右，包含买家端、卖家端、管理员端，虽然业务逻辑比较常见，但是这次开发仍有收获，最重要的一点收获就是 对 Vuex 有了真正的实践和认识。 所以，本文大部分介绍 Vuex 在该项目上的实践以及所踩的坑，另外的部分则是项目中一些其他要点的总结。
过去那臃肿的 Vue 组件前面的几次项目开发，拿到后端接口和需求之后，会按照以下的方式去实现功能：

• 划分出 Components 和 Pages，尽量保证一些组件能够复用。
  
• 抽象出部分可以复用的 SCSS 代码以及设计通用的 style class。
  
• 基于某个 HTTP 库（如 axios）配置并封装一层底层方法，并基于该方法之上书写具体的API 函数。
  
• 在页面和组件内调用上述封装的方法，在函数回调或Promise的then方法里进行数据更新或者做更多的业务处理。
  

好像没什么问题哈？

第1、2、3步基本上是没太大问题的，问题就出在第4步，其结果是导致一个Vue文件越来越大，到后面一个复杂的页面vue文件将会包含如下内容：

• data里大量的数据字段，有控制是否展示元素的，渲染用数据，用于"上锁"的变量等。
  
• 在created或mounted里包含了大量的请求和回调处理。
  
• 在template里使用的组件的属性内，绑定了大量的props。
  

最后的结果就是 vue 文件变得臃肿。
文件越长，可读难度会提高，可维护性会降低。
谁也不喜欢看一个包含了逻辑处理、界面处理、数据处理的冗杂代码文件。
Vuex其实，之前也一直在使用Vuex，不过用的目的仅仅是为了保存一点数据能够全局使用而已，根本没有深入使用，，Mutations等。 本文关于Vuex不会过多介绍其原理以及好处，主要关注实践以及使用心得，Vuex介绍或入门请移步官方文档。笔者所做的，是将关于数据请求和更新，基本都放到了Vuex里，让Vuex“数据集散中心”，而vue组件里，仅仅是进行事件调度（dispatch）和绑定来自Vuex的数据。我们以商品详情页面举例，其包含如下的功能：

• 第一次进入页面根据URL参数中的id请求商品数据。
  
• 根据商品的属性选择更新库存和价格。
  
• 添加购物车并更新小红点。
  
• 下单。
  
• 收藏商品。
  

如果我们不使用 Vuex，代码的结构可能如下：





如果按照上述的方式来写，虽然可以保证关于这个页面的逻辑处理都保留在这个vue文件内，但是却显得十分臃肿，如果后续要加更多的功能抑或是修改，其需要读的代码可能更多。
所以，以上代码示例中的被标记的部分，将是Vuex可以优化的。 最后的代码如下图所示：

关于数据处理的代码，全部封装到了Vuex上了，我们在Vuex层，不仅请求了数据，同时对返回的数据做了判断以及不同的逻辑处理，同时设置Getters使的页面能够基于Getters提供的数据做各类二元判断。Vuex层带来了如下的好处：

• 在不同的页面可以触发相同的Actions，就这个例子，我只要写了一次加入购物车的函数，在各个页面都可以使用了。
  
• Actions之间可以组合使用，通过组合的方式，我们可以更加轻易的实现复杂的业务逻辑，比如添加商品进购物车的同时更新商品数据并更新购物车数据，这样需要写三次HTTP请求的业务逻辑，此时只需要将三个Actions进行组合即可，而这几个Actions还可以在其他地方单独使用。
  
• 直观，一眼看过去，就知道商品模型上有哪些动作，对于 New Guy 熟悉业务逻辑更加方便，也方便开发者检查自己的代码或者函数是否考虑周全。（BTW，在一堆HTML里找逻辑是真的难受）
  
• 减少组件间通信次数，一个中心化的数据仓库带来的好处就是减少了数据层层传递的操作，按照以前的编码习惯，我会大量使用$emit和props来实现父子或兄弟组件通信，而现在，只需要在组件中触发相应的事件绑定相应的数据即可。
  

Vuex后，编码思路清晰不少，因为写完整体的一个功能需要2~3天，而Vuex对于“间断性编程”非常有帮助，能够迅速捡起上一次开发的进度。使用Vuex之后就是按照如下的步骤进行开发了：
（第1、2、3步不变，如前文） 4.构建Vuex的Store模型，定义所需的方法。 5.编写组件并绑定在Vuex上的相关数据和方法。 6.编写触发dispatch使用Vuex存在一定的规范，在官网上已经陈列了诸如，项目结构dispatch最初我的设计是在Action请求数据之后同时也负责所有的跳转逻辑和弹窗逻辑，不过，这样做又让视图层和数据层耦合了，使得我抽象出来的Action的复用性变得极差，同时，在vue文件看到关于视图层的处理才算是比较正常的编写逻辑。【单一职责原则】：action正如上一条原则中提到的要提高action的复用性，那么就要保证需要复用的action只做一个功能，如更新A数据和更新B数据不要直接融合成一个action，而是分别定义两个action，并通过组合的方式来实现一个更复杂的功能，有点类似精简指令集的思想。actions:{ updateA{}, // A 可能在其他地方被单独使用 updateB{}, // B 可能在其他地方被单独使用 updateAandB({dispatch}){ dispatch("updateA"); dispatch("updateB"); }, // 同时触发 A B 的复杂action}为了让dispatch函数拥有Promise风格的处理回调的能力，可以让action的返回值作为一个...created{ this.$store.dispatch('updateA') .then( => { ... })}...而Vuex一般建议在actions进行异步操作，所以为了让代码更加优雅，可以用AA如下编写：// store.jsactions:{ async updateA{ const result = await ajax('/**/**'); if(result){ return Promise.resolve } }}一般使用vuex，会根据实体或者页面来拆分state形成module，一个module里包含其所需的所有actions，states，mutation等。如电商里，一般有，用户这几个实体可以拆成 module。拆分的好处是更加独立直观了，坏处是如果不使用命名空间，可能造成,正好Vuex也提供namespace的配置，参考官方文档即可。这次使用的不足未使用 namespace

虽然总结到了原则里，不过这次并没有使用namespace，算是这次比较大的不足了，解决的办法是 手动 namespace。
将actions的方法名前缀加上该实体名用于区分不同的方法，实在是比较拙劣的手段了。
部分代码仍然有重复书写的情况

情况发生在获取到异步数据之后的代码，一般如下这段代码会大量重复：
if (result.code){ return Promise.resolve(data);}return Promise.reject(msg);复制代码虽然不算多，但是这逻辑仍然有可抽象出来的可能性，下次打算在RootState里添加一个action，用于处理这样的后端返回数据，期望结果如下：actions: { parseResult({}, result){ if (result.code){ return Promise.resolve(data); } return Promise.reject(msg); }, async getA({dispatch}){ const result = await http.get('xx/xx'); return dispatch('parseResult', result); // One line , it's clean }}复制代码3.0 基本在配置上做到极简化了。很久没开发Vue的项目了，记得上一个Vue项目里，仍然有一大堆xxx.congfig.js，而现在，基本集成到了CLI内部了，通过一个vue.config.js可满足大部分开发需求。比以前的配置更加直观了，更多请参考：cli.vuejs.org/zh/，至于插件机制，本次开发未用上，只是在安装第三方包的时候可以用vue add将Vue.use 和 Vue.installplugins本项目是一个多页面应用，总共有3个Vue实例，所以希望能够按需注入想要的第三方依赖如axioslazyload等一些工具库或第三方组件。于是都将其汇总到plugins目录下了。这样封装的好处是，我可以对每个Vue实例按需导入第三方依赖，一行 import 就可以。
一个大型的web app 打包压缩后都不超过500kb，所以就以此作为Benchmark来优化该项目打包后的大小，按需引入第三方依赖（特别是Element和lodash）减少了不少项目体积。不过最主要的还是得学会用webpack analyse tool总之，本次项目主要是刷新了对Vuex的认知，其能够让我们编写的vue组件可读性和可维护性更高。同时，也能够让数据更新这块的代码复用性更高。通过Vuex来构建一个中心化的数据集散中心还能让开发的思路更顺畅，值得学习。参考：Vuex 是什么？
来源：http://www.yidianzixun.com/article/0mM0Ue3S
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！