我在vue中是这样拆分组件的

组件化是一种思维的表现，这种技能映射到人的本质是，一个人是否有能力把一个复杂的问题拆解、简单化的能力。

一、组件化诞生的历史

我们在讨论如何拆分组件之前，是有必要简单的了解一下组件化诞生的一个历史。

前端娱乐圈有一个独有的生态：框架。每年出现的框架层出不穷，根本学不完。但是总的来说还是可以分成两个阶段。

第一阶段: JQ和PrototypeJS。 该阶段解决了浏览器的兼容性问题以及API的遍历程度

第二阶段: Vue、React、Angular。解决了组件化、解耦、复用等问题

在大陆，主要讨论的是Vue和React。 有些人说Vue是framework,而React是library，前者有更多的约束和更加齐全的工具链。而后者更加的自由。但是真的要投入生产的话，依旧需求认为的给React添加很多的约束，而且Vue也是支持jsx的，所以我一直不太赞同React更加自由这样的说话。

在我看来，它们在实际生产开发过程中，在那一堆工具链中，只是API的不同而已。

它们都为前端提供了很好的组件化。而且近一年来两者都不约而同朝着函数式跟进。它们带来的各种hook,给我们带来了不一致的组件化的写法。

二、为什么业务组件越开发越难维护

人的问题

当然是人的问题. 或许产品的问题,或许整个工作流程的问题,或许上面的问题. 这些我们暂且不提,我作为开发, 首先是要管好自己的代码组织.

再次我们先排除其他外界的因素,比如产品经常改需求. 仅从编码阶段来说.

以我们团队为例，我们团队内部员工2个，8个外包，外包兄弟们的招聘标准是远低于内部的。团队人员每个人的编码能力差距还是很大的。项目都是长期维护的，一个业务模块就会有很多人维护，在上面不断的填尿加屎。

在这里并不是说外包人员的编码能力差，我们组就有一个外包的兄弟编码能力、解决问题的能力相当厉害的，比很多内部的都好很多。这里只是从平局值上面来说。

团队成员的水平参差不齐, 顾及到团队协作, 我们在拆分组件的时候需要更加的简单和清晰.

技术问题

业务逻辑和交互逻辑的纠缠不清

2.1 项目现状

可以看出, 改变它组件内部状态的来源非常的多, 维护或者修改的时候,需要翻阅的文件目录和范围就很广. 自然就很难维护.

举一个mixins的例子：

假设它混入了这么多功能。

export default {mixins: [ a, b, c, d, e, f, g],mounted() {console.log(this.whoAreYou)}
} 

这个this.whoAreYou你能够知道来源于哪一个么？ 而如果改成hook的写法来引入某个JS中的变量：

c