前端项目组件化开发见解

如今前端项目组件化开发已经是很普及的了，但是想将一个较为复杂的项目完全拆分也不是一件容易事。
以下是我在项目开发中和平时视频学习中总结出的一些个人经验，对于项目把握的最小粒度发表个人的见解，若有分歧，欢迎探讨指正。

组件化开发的优点

• 降低项目的耦合性
• 降低项目复杂度
• 降低项目开发成本
• 提高开发工作效率
• 提高项目扩展性
• 提高项目的可维护性

怎么设计一个组件

在很多时候我们在考虑开始一个项目时会将整体范围内的设计稿过完，会在自己的脑中有个大概的设计思路。但是我们最多考虑的是组件的复用性，因为组件的复用会大大节约开发时间，但这往往会让我们陷入一个纠结的状态。

通用型组件

通用型组件最大的特点就是满足大多数的业务情况，特点如下：

• 复用性：例如 button、input、icon 之类。
• 可配置性：例如 组件内字体的颜色、图片的规则、按钮的位置、按钮点击事件的处理逻辑等，都是可以做成可配置的。可配置性很强的组件的复用性一定不会太差。

如 Ant Design、Element UI、iView 等等这些优秀的前端组件库将前端组件化的特性发挥到了极致，这些都是通用型组件。

非通用型组件（特定业务组件）

对于非通用型组件，大多数情况是在某个具体项目中，按照项目的特定业务而设计的，特点如下：

• 无复用性：在整个项目中可能只某个页面使用。
• 专一性：专一性可能是所有组件的共性，在这里说是想表明组件对页面结构进行拆分是为了让业务模块独立，让页面结构一目了然。

专一性就是一个组件只干一件事，并且要把这件事闭环走通

有些情况是引入一些通用型组件，但是通用型组件不能完全满足项目的需求，可能需要对组件进行相应的改造，来达到满足项目需求。例如：

• 通用型组件的样式无法满足的时候，要对组件样式进行修改。
• 通用型组件的逻辑无法满足的时候， 要对组件逻辑进行修改，这比修改样式的成本高很多，所以这时候就需要开发者自己去衡量自己写和修改这个组件对于自己哪个成本更高。

组件内部特性

不管是什么组件，为了让组件逻辑更加健壮，需要注意以下几点：

1、参数传入及校验

• 参数类型
• 参数是否必填
• 参数默认值：可选，个人一般会给

2、生命周期

一般要注意的是组件初始化、组件渲染、组件数据变化及组件销毁

3、函数参数校验

这一步用传统的数据类型判断即可。

4、发送事件

用 this.$emit('事件名')，父级组件接收并处理相关逻辑

如何把握项目组件的粒度

最小粒度：不能继续往下拆分的单元（组件）

首先我们要清楚一点，通用型组件的开发的成本要远远高于特定业务型组件，因为通用型组件所要考虑和兼容的是很多不同需求的业务，势必要事无巨细的考虑到不同情况下的方方面面，而通用型组件往往是发布出来开源，供其它人使用的。如果有 bug，别人自然不会用你的了。

对于正在开发的项目，项目周期往往比较紧张，开发时不可能在封装组件的时候面面俱到，所以大部分时候在开发特定业务型组件。

那么，组件的粒度的把控就在于你在开发中封装业务组件时，业务组件下的页面结构要细分到什么程度。举个例子：
页面 PageA 存在 A(search)、B(banner)、C(recommend)、D(classify)等功能点，所以组件是按照A、B、C、D去封装，A、B、C、D下的页面结构往下细化进行页面结构的封装，最后组件的结构为：

• PageA
  • A
    • A1
    • A2
  • B
  • C
    • C1
      • C11
  • D
    • D1

以上最小粒度为 C11，但对于不同的开发者来说 C11 不一定是最小粒度，他可能会细化出 C111 和 C112，并没有说继续细化会错，也没有说粒度为 C11 就是最佳方案。

所以，如何把握项目组件的粒度，没有标准答案，但是一定不推荐的是一个页面没有细化组件或者组件的深度达到第五阶第六阶，通常情况下第二三阶是在项目中比较合理的粒度，因为在移动端项目里第二三阶组件都没法将页面结构表达清楚，那更高阶的也不一定能表达清楚。