关于前端组件化、状态管理规范化的思考

说起前端组件化是这几年老生常谈的话题，笔者就不在这里对前端组件化思想的发展史、优劣做详细的介绍。今天主要与大家分享一下，笔者在开发中从初期的小项目，到后期的项目功能迭代，功能模块越来越多，项目越来越大，组件化规范制定不够完善，多人团队协作开发导致的一些问题，与笔主自己处理的方案的思考。

二、发现、提出问题

1、三张图说明一个业务模块功能迭代图。

第1版

组件单向数据流，父组件状态单向传输子组件

第2版

随着功能迭代，非父子组件会共享一些状态。 此处由于非父子组件间状态共享不复杂，优先使用状态提升（状态提升，我们需要把子组件间共享的状态，提升到容器组件进行管理，并有容器组件下发到子组件）解决此类问题。

第3版

随着更多的功能迭代，模块分层越来越多，夸多层组件状态共享越来越复杂

状态管理redex、vuex就是为了解决此类问题而出现。

通过以上的项目模块迭代周期的发现，不可避免的出现多组件状态共享。 通常处理共享状态有三种方式：

1. 状态提升，我们需要把子组件间共享的状态，提升到容器组件进行管理，并有容器组件下发到子组件。
2. 状态管理redux、vuex。
3. 事件机制，子组件改变共享的状态，通过事件管理模块emit分发出去，需要同步更改状态的子组件通过on接收更改事件。

引入状态管理就真的能解决所有的问题吗？

1. 组件哪些状态需要提取到状态管理？
2. 如何避免滥用全局状态导致项目混乱？
3. 容器组件、展示组件如何划分？
4. 多人协作开发组件规范、风格不统一，组件间共享状态双向修改规则不统一，新人加入学习成本高。

三、解决问题

笔者认为解决问题的方法，就是制定相应规范，保证团队代码风格统一。

1. 容器组件与展示组件开发规范。
2. 哪些组件状态应该提取到状态管理，状态管理开发规范。

请看下图：

容器型组件：主要是获取、更新、提交、删除内含展示组件状态数据，不包含任何Virtual DOM 的修改或组合，也不会包含组件的样式。

展示型组件：展示型组件主要表现为组件是怎样渲染的，包含了Virtual DOM的修改或组合，也包含组件的样式，同进不依赖任何形式的store。一般可以写成无状态函数，但实际上由于很多展示型组件里依然存在生命周期方法，所以不一定都是无状态的组件。

说明：

1. 项目初期版本，只有一个容器组件A，容器A包含三个展示组件A1、A2、A3，所有共享状态都有容器A管理。
2. 随着项目迭代，容器组件A会分裂出两个新模块容器组件B、C。
3. 容器组件B、C分别包含展示组件B1、B2，C1、C2，且B、C之间存在共享状态。
4. 容器组件间共享状态数据，统一由状态管理store管理。

规范：

1. 展示组件必须在容器组件中使用，除了独有的状态，其他共享状态统一由容器组件管理。
2. 展示组件涉及修改共享状态的操作，例如点击事件，需要把点击事件通过无状态回调函数抛到容器组件，由容器组件统一做状态获取、更新、提交、删除等等操作。
3. 父子容器组件共享状态，子容器只能读取父容器组件共享状态，不能进行修改（例如子容器不能通过无状态回调函数抛到父容器，由父容器更新状态），保证单向数据流。
4. 子容器修改父容器或者修改非父子容器共享状态唯一途径，通过状态管理store统一修改。
5. 由于容器间共享状态不能双向修改，所以状态管理store会保存大量的共享状态数据，需要通过系统模块、容器组件名分层注册需要状态共享的容器组件state。