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

• 苏格团队
• 做者：Tomey

1、开篇

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

2、发现、提出问题

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

第1版

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

第2版

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

第3版

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

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

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

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

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

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

3、解决问题

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

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

请看下图：

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

展现型组件：展现型组件主要表现为组件是怎样渲染的，包含了Virtual DOM的修改或组合，也包含组件的样式，同进不依赖任何形式的store。通常能够写成无状态函数，但实际上因为不少展现型组件里依然存在生命周期方法，因此不必定都是无状态的组件。

说明：

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

规范：

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

实例

写了一个vue+vuex的基础实例，可供参考。下载 github

4、结束

文章到此结束，写这篇文章目标主要是记录本身对于组件规范的思考,欢迎各位大佬提出本身的看法，文章有误的地方请你们及时指正~