前端组件化是这几年老生常谈的话题，笔者就不在这里对前端组件化思想的发展史、优劣做详细的介绍。在开发中我们经常会遇到，从初期的小项目，到后期的项目功能迭代，功能模块越来越多，项目越来越大。组件化规范制定不够完善，多人团队协作开发组件耦合度高、复用性低、代码冗余严重，导致项目维护成本越来越高。在此写下笔者自己处理上述问题的思考。
发现、提出问题
第 1 版：组件单向数据流，父组件状态单向传向子组件。
第 2 版：随着功能迭代，非父子组件会共享一些状态。此处由于非父子组件间状态共享不复杂，优先使用状态提升（状态提升，我们需要把子组件间共享的状态，提升到容器组件进行管理，并由容器组件下发到子组件）解决此类问题
第 3 版：随着更多的功能迭代，模块分层越来越多，跨多层组件状态共享越来越复杂。
第 4 版：状态管理 redux、vuex 就是为了解决此类问题而出现。
通过以上的项目模块迭代周期的发现，不可避免的会出现多组件状态共享的情况。通常处理共享状态有三种方式：
- 状态提升，我们需要把子组件间共享的状态，提升到容器组件进行管理，并由容器组件下发到子组件。
- 状态管理 redux、vuex。
- 事件机制，子组件改变共享的状态，通过事件管理模块 emit 分发出去，需要同步更改状态的子组件通过 on 接收更改事件。
上述的三种方式会存在哪些问题？
- 组件哪些状态需要提取到状态管理？
- 如何避免滥用全局状态导致项目混乱？
- 容器组件、展示组件如何划分？
- 多人协作开发组件规范、风格不统一，组件间共享状态双向修改规则不统一，新人加入学习成本高。
解决问题
笔者认为解决问题的方法，就是制定相应规范，保证团队代码规范风格统一。
- 容器组件与展示组件开发规范。
- 哪些组件状态应该提取到状态管理，状态管理开发规范。
请看下图：
容器型组件：主要是获取、更新、提交、删除内含展示组件状态数据，不包含任何 DOM 更新。
展示型组件：展示型组件主要表现为组件是怎样渲染的，包含了 Virtual DOM 的修改或组合，也包含组件的样式，同时不依赖任何形式的 store。一般可以写成无状态函数，但实际上由于很多展示型组件里依然存在生命周期方法，所以不一定都是无状态的组件。
说明：
项目初期版本，只有一个容器组件 A，容器 A 包含三个展示组件 A1、A2、A3，所有共享状态都有容器A管理。
随着项目迭代，容器组件 A 会分裂出两个新模块容器组件 B、C。
容器组件 B、C 分别包含展示组件 B1、B2，C1、C2，且 B、C 之间存在共享状态。
容器组件间共享状态数据，统一由状态管理 store 管理。
规范：展示组件必须在容器组件中使用，除了独有的状态，其他共享状态统一由容器组件管理。
展示组件涉及修改共享状态的操作，例如点击事件，需要把点击事件通过无状态回调函数抛到容器组件，由容器组件统一做状态获取、更新、提交、删除等等操作。
父子容器组件共享状态，子容器只能读取父容器组件共享状态，不能进行修改（例如子容器只能通过无状态回调函数抛到父容器），保证单向数据流。
子容器修改父容器或者修改非父子容器共享状态唯一途径，通过状态管理 store 统一修改。
由于容器间共享状态不能双向修改，所以状态管理 store 会保存大量的共享状态数据，需要通过系统模块、容器组件名分层注册需要状态共享的容器组件 state。
