datagrid只传入了一部分的数据 未显示全_「实践思考」Vue中使用Mixin来管理异步数据...

前言

不知不觉写文章没有以前频繁了，主要是转到React后，花费了一些精力从使用React到搞懂，再加上花了大价钱入手的红宝书不能不看所以说这个月除了工作时间都是在看红宝书计划。先沉淀下自己。

本文内容仅供参考，本方案也是一个不成熟的考究，欢迎朋友们给我一些优化的建议。

异步数据的问题

为什么会有一个异步数据的管理解决方案？我们为什么要去进行管理它？大家都知道在很久之前，我们Api调用方法还写在页面上面的时候，你自己都可以想象到这个方式是有多糟糕了。随之而在的就是nwtwork拆分，大家都有条不紊的将api的接口拆分出去，有单独写成函数文件的，有直接做约定式的，大体上不变的就是剔除了页面上的this.$http.get.....等等方法。

但是，我们的问题解决了吗？

事实上并没有，在最近浏览一些开源项目的时候，我们都可以频繁的看到如下类似的业务代码

demo

基本逻辑其实就是请求一个列表数据，这个过程中会触发viewLoading的更新，更新完了后隐藏loading的显示，那么当我们有多个需要管理的异步数据的时候，就可能会转化成loading和disable的行为控制，随着单业务体量的增加，慢慢的，data和methods会渐渐的分散，形成礁石代码。当我们再一次添加迭代功能时，就像是在礁石群中行驶的轮船，可能会发生触礁风险。

那么，问题就回到了标题，对于在option中的异步代码该怎么去做处理呢？

官方给我们提供了mixins的混入规则，那么我们可以美滋滋的将其进行混入的时候，这样是不是就解决问题了呢？看上去是的，mixins很好的解决了我们代码复用的形式，但同时也又新暴露出来了一些问题，由于mixins的机制，被混入的代码是不可知的。所以说当你使用mixins的时候就需要注意两边是否都定义了相同的东西，会不会产生覆盖的冲突。

• 代码意外冲突
• 混入不明确
• 心智负担大

那么我们是不是可以思考，在mixins上面做更多的事情，解决掉mixins的一些负担的同时能够对其进行改造，这样的话对于代码的管理和维护也会有一个不错的效果。

如何解决问题?

在解决问题的时候，我参考了umi的dva model，但如果说将数据放在Vuex中管理其实并不好，所以我还是把mixins拖出来鞭尸了。 最后的最后，我将mixins改的面目全非了。最后的结果就是将这些异步数据代码单独拆分出来，形成一个数据访问层作为处理，在这里我们对数据进行处理，当我们这些数据或者逻辑需要被更改的时候，我们只需要单独的对数据访问层这个模型进行修改，就可以快速的进行替换逻辑了。

什么是数据访问层？

很多人会发出疑问，文章开头中的数据访问层是个什么东西，从字面意思上大部分人获取就知道了该层的作用，其实它就是用来和Model数据模型层沟通的桥梁，也可以看成是controller中剥离出来的一个行文模式，我们暂且称呼它为“数据访问层”，我们仅仅需要知道这是一个沟通工具就好了。

• JSON数据获取
• Api数据获取
• 第三方数据接入
• 其他

以上种种都属于数据访问层。这些代码往往和业务逻辑还有后台数据挂钩，做一个承上启下的桥梁作用。

Mixin的Model设计

既然要对mixins做出处理，那么就尽量让它的语法更加贴合团队，因此，我们在项目的页面路径下创建一个model.js来进行数据访问层的声明，为了考虑对其Api的学习程度，将其修改为一个类vuex moudule的Api来进行的。

example

export def