前端领域的组件化究竟是在谈什么

1.为什么要实施前端组件化？

在项目开发中，页面和功能大都拆分为多文件来实现，多文件管理逐渐暴露出以下问题：

• 相似的业务代码无法复用：X同事实现了一遍A页面，Y同事要实现一个和A页面类似的B页面，发现X同事的代码无法有效复用，只好重新再写一遍。
• 多人重复实现同一功能：X同事完成了A功能，Y同事开发时要做同样的功能，但是并不知道X同事已经实现了，又重新写了一遍。

随着项目的不断迭代，以上问题便会导致：

• 代码体积不断增加，冗余越来越大；
• 业务逻辑复杂度不断增加，逻辑的可扩展性、可维护性、健壮性越来越差；

而产生以上问题的原因主要体现在：

• 相似代码重复开发；
• 复用功能代码的方式是简单粗暴的复制粘贴；
• 团队内协作开发导致代码耦合度高，后期维护难；

随着项目的迭代，从长期维护的稳定性和可操作性方面来看，大多数人都想过无数次重构和优化，却总是不敢轻易“动”。所以在前端项目工程化的前提下，引入了前端组件化，从功能模块的复用及多人协作层面进行解耦。

2.组件化：前端解耦的有效利器

2.1 什么是前端组件化？

前端的组件化，其实是对项目进行自上而下的拆分，把通用的、可复用的功能中的模型（Model）、视图（View）和视图模型（ViewModel）以黑盒的形式封装到一个组件中，然后暴露一些开箱即用的函数和属性配置供外部组件调用，实现与业务逻辑的解耦，来达到代码间的高内聚、低耦合，实现功能模块的可配置、可复用、可扩展。除此之外，还可以再由这些组件组合更复杂的组件、页面。

上面提到了要对项目进行拆分，那经常听到的模块化与组件化都涉及了对项目的模块拆分，指的是一回事吗？

组件化≠模块化。模块化是从文件层面上，对代码或资源进行拆分；而组件化是从设计层面上，对用户界面进行拆分。前端组件化更偏向UI层面，更多把逻辑放到页面中，使得UI元素复用性更高。

换句话说，页面上所有的东西都可以是组件，可以把页面看作大型业务组件，它又能拆分为多个中型业务组件，然后可以再拆分成多个复合组件，复合组件再拆成多个基础组件，直到拆成Dom元素为止。实际项目开发中，只需要应用这些组件，像搭积木一样完成页面的搭建就可以了。

图1  页面与组件间的关系

2.2 组件化思维

组件化思维的精髓是独立、完整、自由组合。以此为目标，尽可能把设计和开发中的元素独立化，使其具备完整的功能，通过自由组合来构成整个页面/产品。

2.3 组件分类

一般常见的组件可以划分为这四种：基础组件、业务组件、区块、页面。

图2  组件分类与关系图

基础组件：不包含业务，具备独立具体的功能，比如button、input、select等组件。项目中不需要关心也无法修改组件内部的代码，通过组件定义的props配置来实现不同的功能；

业务组件：由基础组件组合而成，含有业务逻辑的组件；

区块：由基础组件和业务组件组合而成；项目中对于区块代码可以进行任何改动，这是区块和业务组件的最大区别；

页面：呈现给用户的页面，也可以看作是业务组件。

2.4 组件化的特点

网上对于组件化并没有一个明确的定义，但是在提到组件化的时候都会提到高内聚、低耦合。也就是希望每个组件对内做到各个元素紧密结合，互相依赖；对外和其他组件的联系最少且接口简单，可复用可组合。组件化的意义在于提效，希望可以交付可用的、直观的、可组合的业务形态。

如果项目实现了组件化，那么写代码就具有了更高的灵活性，可扩展性和可维护性。

图3 组件化特点

2.5 组件化开发后的新面貌

组件化以后，一个页面可能是这个样子的：

图4 页面与组件的构成

项目可能是这个样子的：项目内部对应多个页面，页面内部对应多个组件，组件内部又可能对应了多个不同的库。

图5 项目、页面与组件的关系分布

3.实际业务开发：具体问题具体分析

3.1 组件设计原则

无论是基础组件还是业务组件，在设计时都应遵循一定的原则：

单一性：一个组件只专注做一件事，且把这件事做好。一个功能如果可以拆分为多个功能点，就将每个功能点封装为一个组件，但并不是组件的颗粒度越小越好，只要将一个组件内的功