从对 Vue 中 mixin 的批评

向的，虽然 mixin 模块在当初被定义时并不知道将来会有哪些组件引用它的，但如果当下你十分确定某个消费它的组件中注定存在 world 方法，你就可以在 mixin 模块中调用 this.world() 。这种关系还能延申至 mixin 之间，无论是平行关系还是嵌套关系下的 mixin 模块(mixin 模块可以继续引用其他的 mixin 模块)，它们之间都可以互相访问变量和方法。

在这里你是不是已经嗅到了危险的味道?

看上去方便至极了!可一旦需要对代码进行维护时，问题就暴露了，哪怕你只是想理解某个极小的代码片段。

假设某个同事在组件中偶遇了 hello 方法，想给它新增一个参数来实现更多的功能——这看上去不起眼的小事在实际操作起来却比登天还难。因为他根本不知道该方法是在哪个 mixin 模块中被定义的，他所知道的只有方法属于 this，于是他不得不翻看每一个 mixin 的定义。

退一步说即使他在某个 mixin 中找到了该方法的定义，又会遇到另一个难题：不敢修改这个函数的签名。虽然他可以知道有多少个组件文件引用了这个 mixin 模块，但是他不知道有多少处直接或者间接的调用了这个方法。也就是说这一次修改会造成的后果和带来的影响难以评估。

所有这些问题的根源在于组件与 mixin 间，mixin 与 mixin 间的依赖是隐式的。也就是说当 A 模块依赖 B 函数时，这种关系既不是通过显示的声明(比如 import 语句或者依赖注入的方式)取得，也不是通过公共约定(例如 windows 对象上存在 getComputedStyle 方法)确定下来的。

这种关系也让 IDE 武功尽废，我发现解决这个问题的最后方式竟然是 Ctrl + C(复制)，Ctrl + V(粘贴)，Ctrl + Shift + F(全局查找)，Ctrl + H(文本替换)。

隐式依赖不仅会对脚本代码带来负面影响，对样式代码也会。flex 布局是一个正面的例子：如果你想控制父容器内孩子元素的布局，只需要修改父容器上 flex 有关的属性即可，你不依赖孩子元素的 DOM 结构，更不依赖孩子元素上的样式;而一个反模式的例子是 text-overflow: ellipsis 属性，单一的该样式属性是不足以自动省略容器内的文字，容器还需要满足 1) 宽度必须是 px 像素为单位 2) 元素必须拥有 overflow:hidden 和 white-space:nowrap 样式。而 text-overflow 属性本身并没有告知我们还需要这些“配套设施”。

（编辑：桂林站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!