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 组件设计原则
无论是基础组件还是业务组件,在设计时都应遵循一定的原则:
单一性:一个组件只专注做一件事,且把这件事做好。一个功能如果可以拆分为多个功能点,就将每个功能点封装为一个组件,但并不是组件的颗粒度越小越好,只要将一个组件内的功