- 苏格团队
- 作者：Tomey
一、开篇
说起前端组件化是这几年老生常谈的话题，笔者就不在这里对前端组件化思想的发展史、优劣做详细的介绍。今天主要与大家分享一下，笔者在开发中从初期的小项目，到后期的项目功能迭代，功能模块越来越多，项目越来越大，组件化规范制定不够完善，多人团队协作开发导致的一些问题，与笔主自己处理的方案的思考。
二、发现、提出问题
1、三张图说明一个业务模块功能迭代图。
第1版
组件单向数据流，父组件状态单向传输子组件
第2版
随着功能迭代，非父子组件会共享一些状态。 此处由于非父子组件间状态共享不复杂，优先使用状态提升（状态提升，我们需要把子组件间共享的状态，提升到容器组件进行管理，并有容器组件下发到子组件）解决此类问题。
第3版
随着更多的功能迭代，模块分层越来越多，跨多层组件状态共享越来越复杂
状态管理redux、vuex就是为了解决此类问题而出现。
通过以上的项目模块迭代周期的发现，不可避免的出现多组件状态共享。 通常处理共享状态有三种方式：
- 状态提升，我们需要把子组件间共享的状态，提升到容器组件进行管理，并有容器组件下发到子组件。
- 状态管理redux、vuex。
- 事件机制，子组件改变共享的状态，通过事件管理模块emit分发出去，需要同步更改状态的子组件通过on接收更改事件。
引入状态管理就真的能解决所有的问题吗？
- 组件哪些状态需要提取到状态管理？
- 如何避免滥用全局状态导致项目混乱？
- 容器组件、展示组件如何划分？
- 多人协作开发组件规范、风格不统一，组件间共享状态双向修改规则不统一，新人加入学习成本高。
三、解决问题
笔者认为解决问题的方法，就是制定相应规范，保证团队代码风格统一。
- 容器组件与展示组件开发规范。
- 哪些组件状态应该提取到状态管理，状态管理开发规范。
请看下图：
容器型组件：主要是获取、更新、提交、删除内含展示组件状态数据，不包含任何Virtual 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。
实例
写了一个vue+vuex的基础实例，可供参考。下载 github
四、结束
文章到此结束，写这篇文章目标主要是记录自己对于组件规范的思考,欢迎各位大佬提出自己的见解，文章有误的地方请大家及时指正~