在vue中是这样拆分组件

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

一、组件化诞生的历史

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

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

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

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

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

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

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

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

人的问题

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

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

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

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

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

技术问题

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

2.1 项目现状

以该图为例, A B C 分别是父子孙组件. 当我们要控制其中一个组件的状态的是, 可以通过很多方式来进行控制. 这些方式的来源有可能是全局变量、vuex、时间总线、来自自己父组件或子组件的改变等等.

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

举一个mixins的例子：

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

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

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

const { IamI } = myHome()

const { IamI as me } = myHome()

这就很简洁干净。在你维护代码的时候，可以很好的进行溯源。 而上面的一切，导致难以维护的原因总结来说有两个：

• 混用业务变量和UI变量
• 不区分受控组件和非受控组件

下面我会实际例子分别介绍这个两个概念。而基于hooks的复用才是我们现在解决组件化复用的更好的选择。

2.2 理想目标

基于hook的理想模型

依旧是A B C 三个组件.但是A B C三个组件外边飘的那些箭头不存在了. 所有能够控制它们的内部状态的方式都集中 在了controllers上面.

其中controllers部分的组织形式和vue的composition api宣传图表现一致。