因业务需要，开发了一个款 vue template视图分离 而模型共享 ，基于webpack加载器，内部使用了vue官方的组件分析器。有相同需求的欢迎使用。小弟水平有限,只会一点,请大神赐教！
适用于：组件业务逻辑较复杂，分离组件成本高，组件间数据通信难以维护，html代码多，而vuex也解决不了根本问题的相关场景。
思路有点意思,不过实用性有点怀疑. 是为了抽离共性的视图?但视图分离,模型共享,不会导致维护上的风险吗? 组件之间使用自己的数据或prop或vuex本来就是这套体系最大的约定,你这样感觉就是一时爽啊.
组件业务逻辑较复杂，分离组件成本高 这两点之间有联系吗? 组件间数据通信难以维护,是难以维护,还是你懒得维护? 如果是难以维护,你这样hack一下岂不是更难维护?
@178220709 不可否认，在实际开发中，好的情况是各组件功能单一 ，每一个组件应该遵循各自职责，粒度适当的原则。 而我开发加载器，只是特殊情况的特殊办法。这其实也是没办法的办法。 你可以想象一种耦合度较高的业务场景，类似vs code的网页版编辑器 ：中间编辑区 ，编辑区周围有一些状态栏目和工具条（他们数据共享，方法来回调用，共同来管理业务逻辑）， 我起初也尝试过vuex 的store ：state共享状态 dispatch 、mutations 定义修改方法。 也用过父子组件之间订阅的on、 emit ，$parent， 但最后都放弃了 因为看似简单，实际操作起来就发现不容易，因为他们业务关联太紧，混在一起没法细分，
所以最后的方案是：ViewModel层我用mixin做了混入 ， template 层目前就想到这种方案，我也希望有人给我更好的方案
template require我也不会大范围用,要用最多用到一两个地方，也不会推荐滥用，针对特殊情况可以一试，如果滥用就没有必要使用vue这套了，在项目维护上我觉得没啥问题。如果有，欢迎提出。
开发这个加载器的初衷：
1、就是vue 的js 、css（less、sass）可以做到分离，能通过 import/require/mixin引入整合，为啥template不能，我就开始去尝试
2、在这个项目一开始，是分离还是不分离这一块逻辑，就一直想这个问题，目前想到了这个方法
mixin是一个很好的方案啊, 如果你在vm的mixin和这里template的mixin做一个整合,一定程度倒是可以控制住这里的复杂度. 你mixin进去的,不单单是一个vm的一部分data,而是一个完整的充血模型,包含了这个组件的数据,函数,事件绑定,监听… 而这个用vuex是完全可以做的.
这个不是强行分离,而是重构你的代码,如果你能把组件完整的抽象出来,那才说明你真的梳理清楚了这个组件的职责和边界,如果这样混在一起,那还是部分逻辑在组件,部分逻辑在父组件,你做功能迭代,也没办法明确这个迭代是应该再组件里面做,还是父级的view里面做. solid法则,你至少已经违背了单一职责和开闭原则.
站在理论的角度，你说的都对 ，我们都要遵循 编码原则和开发规范。
mixin的确是目前好的方案，这也是我的主要思路，但只能用到了js，不能混入template，而且你不知道他该放在何处， 用v-html 定是行不通的，在编译完成后插值，没有任何意义， 也编译不到第三方ui组件，它没有提供angular1.x中类似的$compile 服务，不能手动编译，而rende函数也不灵活。 mixin 主要扩展的是js能力 而不是temlpte视图， 所以还是不能解决问题。
// 这里我解释了为啥不能只用mixin混入来解决问题
vue-template-merge-load其实做的很简单，只会在编译前把代码移了个位置，这并不存在任何风险。 在我描述的业务场景中你也会看得出，这是多组件平行运行，数据实时交互 ，并没有父子关系， 如果用vuex来做会有一堆变量和方法来控制，而组件间调用需要来回调用一个类似第三方插件 这也无形中增加了维护成本，最后就算成功分离可能的情况：模块功能没分离，js 却来回跳满天飞， vuex也是一种方案，但不是万能的 。 版本迭代和后期维护这是一个权衡点，这也是我们讨论的重点，项目不会一直迭代 能确认需求，也能预见项目周期。因素不大，不用太担心。 这种复杂的业务场景只有做起来才知道 没有最好只有最实用。 只有从这个角度思考才知道该怎么做 为什么要这么做
关于这块逻辑 分离or不分离， 不管是基于理论基础 还是实际操作中，不想展开讨论了。 因为不管怎么做，最后的都会有争议，分有分的好处 不分有不分的好处 。没有绝对的好与坏。 关于mixin 或者其他方案可以多多交流
