组件化作为一种开发模式，在代码复用、提高开发效率方面得到认可。 组件化思想适用于移动端、Web前端、PC端、电视端等多种类型的客户端和前端开发
本文主要阐述了ichi知识WEB前端团队如何结合自身的业务特点，探索和实践高效的前端组件方案。
组件化：前端解耦和提效利器
随着前端业务的发展，代码的体积越来越大，业务的逻辑复杂性也随着迭代而越来越高。
组件化的意义在于提高效果，交货为可用的、直观的、可组合的业务形态。
目前，行业内前端组件化大致分为三类：
面向运营人员：运营人员主要进行页面的制作、设计，组件像乐高积木一样拼凑在一起，针对特殊的组件，让开发人员定制实现，有几个静态的和
面向设计人员：设计师主要参与页面设计，可以将设计稿直接转换为前端代码，省去蚂蚁imgcook这样的前端开发流程。 另外，对于复杂的逻辑，也可以交给开发者进行二次开发。
面向开发人员：这也是最传统的开发模式，主要针对动态页面。 对于需要后端接口协同工作的场景，每个页面上的组件都是公用组件，因此可以从每个页面中调用它们。
ichi ei知识的组件化设计是为第三个，也就是开发者设计的。 在开发级别，组件复用可减少冗馀代码，实现功能与业务逻辑的解耦，组件扩展可实现提高可拓展性、可维护性
业务场景：项目多且独立、又要保持产品一致性
关于具体组件的分割，目前行业没有统一的标准，需要与具体的业务场景进行配合。 这是因为在不同的场景中，组件分割的力、程度可能不同。
眼驰知识WEB前端项目配置
从眼驰知识WEB前端的项目结构可以看出，知识WEB前端的项目很多。 我们将项目按类型划分，各分类下的项目为独立项目，完成相关业务功能，各项目独立开发、独立布局，且项目间直接业务关联项目有店铺等实体，这些实体的UI样式在各个项目中必须基本一致，同时弹窗、加载等通用UI元素也必须保证样式的一致，从而在保持产品体验一致性的同时提高开发效率，提高代码的复用性
这里需要简要说明一下，我们的Web端组件化思维和知识移动端团队在组件化思维上不太一样。 移动端往往从业务和功能的纵向划分组件，也称为模块化。 每个组件或模块都包含UI和业务逻辑。 例如，播放器的组件广播控制播放控制和UI样式，共享组件包含共享功能和弹窗，支付组件包含支付过程和收银台支付结果页面。 另一方面，Web前端的组件化偏向于UI级别，逻辑往往放在页面上，也符合Web开发的特点。 UI元素组件抽离
感兴趣的学生可以了解移动端组件化的设计思路。 传送门在这里。 是艾智怡知识移动端组件化的探索与实践。
基于上述背景，知识网络前端进行了相应的组件化建设，目标是：
复用性更高
根据业务特点，将组件分为横向和纵向，以组件为单位承担业务需求。 虽然以UI组件为中心，但是对于比较独立的功能也进行了纵向的组件提取。
1. 代码复用，提升开发效率
由于单独开发、调试、发布组件并由业务方调用，因此业务方只需将精力集中在业务本身上。
2. 组件独立开发维护，与各项目解耦
组件调用必须显式输入、输出参数，验证参数，并提供合理的错误提示； 如果每个项目都涉及到对业务组件的引用，则组件库会自动确定是在项目中(前端路由)跳转还是在项目外)跳转。
3. 更方便的组件调用，更合理的路由跳转
组件库需要完整的使用说明书，以支持在线调试，并使商务用户更方便、更方便地使用。
4. 组件文档化，支持在线调试，降低组件使用门槛
任何工具的设计都需要从实际的业务场景出发。 回到我们的场景，思考如何管理项目之间依赖的通用组件资源非常重要。 组件的设计在方便业务方面使用的同时，还包括组件自身开发的整体设计
我们认为组件化的关键是组件的分层和分割，明确组件的层次和定义层次对组件化系统来说很重要。 在此，根据EMC独特的业务将组件分层如下(如图) :
">为了更好的理解，我们将层级之间的关系进行如下展示（图示）：
由于 Card 组件由多个 Item 组件组成，所以 Card 组件与 Item 组件的关系如下：
card组件
基于以上设计，我们简单总结一下，组件按类别可分为：基础组件、业务组件。
其中基础组件可分为：基础 UI 组件、基础工具组件；业务组件可分为：item 组件、Card 组件、区块组件、功能组件、页面组件。
基础组件
基础工具库：这是一组 JS 库，无 UI 界面，包含项目所使用的基础功能，如：网络请求、页面埋点、异常上报、与 Native 交互的 CallNative，以及一些常用utility工具等等。
基础UI组件：包含了：文本、图片、按钮、布局、loading 加载、toast 提示等常用的UI组件。
业务组件
Item 组件：业务组件的最小单元，比如：列表中的一项，宫格中的一项，金刚位中的一项、轮播图中的某张图片等等。业务方可引入所需的 item 组件或组合item组件来完成页面的展示。
Card 组件：这是一套服务于 Card 化所对应的一套组件，这里简单介绍一下 Card 化：后端返回的是一套基于 Card 的数据结构，每个card数据与前端某一个UI组件一一对应，通过对数据的配置来实现对前端展现的控制。Item 组件也可以属于 Card 的一部分，由 Card 组件组合多个 Item 组件来进行界面的展示。
区块组件：是为了完成某一个区块的 UI 展示，而抽离出来的组件，供业务方使用，比如：评论组件、评价组件等。
功能组件：是为了完成某一项具体的业务功能而抽离出的组件，比如：播放器组件、发布器组件、分享组件等。
页面组件：也叫路由组件，这是基于微前端所抽离的组件，我们的某个页面也可以当做组件，从而被其他项目所使用。
技术实现
由于基础组件、区块组件、功能组件已经是非常通用的设计，这里我们重点介绍一下业务组件中的Card 组件、Item 组件。需要注意的是，不管是基础组件还是业务组件，我们在设计之初都需要让其符合以下设计原则。
设计原则
我们的组件设计原则需满足如下要求：
需要统一技术栈，保证组件在同一技术生态。
单一职责，一个组件只专注做一件事，且把这件事做好。
追求无副作用，输入一但确定，输出就是固定的。
可配置，一个组件要明确它的输入和输出分别是什么，同时入口处检查参数的有效性。
粒度适中，划分粒度的大小需要根据实际情况权衡，太小会提升维护成本，太大又不够灵活和高复用性。每一个组件都应该有其独特的划分目的的，有的是为了实现复用，有的是为了封装复杂度 实现业务清晰的目的。
适当的包体大小，便于页面快速加载。
完善的使用说明文档。
数据协议
在项目初期，我们的 H5 移动端首页：https://zhishi.m.iqiyi.com 是基于后端的 Card 化数据，由后端数据选择前端的 Card 组件、Item 组件来进行页面的展示，在这种场景下，我们的 Card 组件、Item 组件首先被设计出来，与此同时我们设计了一套前端数据协议（可以理解为数据格式定义），后端 Card 数据经过前端协议后，转换成前端的 Card 数据结构，在此数据结构的基础上进而抽离出 Card 组件、Item 组件。
后来发现我们大量的页面并非基于 Card 化数据，而是基于不同的 API 、不同的数据结构，如何让这些页面也复用我们的 Card 组件、Item 组件呢？为此我们需要不同的转换器，将后端的接口数据根据前端数据协议转换为 前端的数据格式（如下图），这样无论后端接口数据如何改变，我们只需更改转换器的逻辑，而无需更改前端组件代码，进而复用我们的 Card 组件、Item 组件。
UI 实现
在具体的 UI 实现方面，我们拿下图中我们的业务 UI 组件库内常用的两个Item举例：课程列表 Item、课程宫格 Item 。
不难发现Item 组件主要是由 图片、文本组成的，而图片、文本恰好又属于我们的基础 UI 组件库范畴。
图片组件，是在保留原生`img`的特性前提下，支持懒加载，自定义占位、加载失败占位、图片获取策略（webp or jpg）；
文本组件，支持 单行、多行截断。
所以我们在编写 Item 组件的时候只需组合图片、文本组件即可，这样后期随着我们组件数量增长，当我们开发其他 Item 组件的时候会变得非常轻松，效率也得到极大提升。
还有一点需要注意的是：可能我们的组件需要同时满足在移动端手机、平板、 PC端的正常展现，这样就会涉及到布局以及屏幕适配的问题，同时也涉及到设备旋转带来的屏幕尺寸动态变化的问题。所以在组件在设计的时候 宽、高不能定死，而是引用方设定的，同时我们需要在组件内兼容不同屏幕的适配样式，也可以分别导出不同屏幕的适配样式文件供引用方使用。
构建工具
由于基础工具库 是一组 JS 库，所以我们使用 rollup 构建，它是一个高效的 library 模块打包器，可以使我们的组件更加轻量、简洁，同时生成 es, umd 格式文件供前端调用。
UI 组件库，我们使用 VUE 作为前端技术栈，使用 Webpack 进行构建，业务组件项目支持导出多个组件入口，支持业务组件按需加载（如下所示）
import { item40000, item40001, item40010, item40011} from '@iqiyi-kpp/ui-biz-vue'组件支持按需加载就意味着，各组件入口需要单独打包，这会涉及到各入口的公共资源重复引用的问题。
我们可以使用@babel/runtime，@babel/plugin-transform-runtime，设置 core-js 为 false，做大限度减小 babel 转换的包体。
使用 babel 命令打包 JS 文件（不使用 webpack），减小 JS 包体。
使用 webpack externals 将第三方依赖，以及每个组件的公共引用提出来，通过 require 的方式去引用，而不是重复打包到每个组件内。
技术文档
我们的组件库开发完成，并不意味着组件化这件事就算做完了，一个良好的组件库往往需要有一个良好的文档说明，这样会降低团队成员的沟通成本，所以基于 storybook 我们搭建了 UI 组件的文档站点，比如下图的基础 UI 组件库文档，可动态展示最新的组件版本，同时支持 UI 组件在线调试，更能直观的表达组件样式与交互，增强了组件的易用性。
总结
前端组件库一般是放到公司的私有仓库上，通过 npm 进行维护的，使用方需要 引用并打包到自己的项目内才能使用。随着 webpack5 module federation 的流行，也可以将组件当作微模块单独发布，各使用方可通过动态 load module 的方式进行引用。
由此也可以看到前端组件化的优势：可以很大程度上降低系统各个功能的耦合性，这对前端工程化及降低代码的维护成本来说，是有很大的好处的。
爱奇艺知识 WEB 前端组件库经过不断的完善和迭代，基本实现了组件化的全部目标，组件通过独立开发、测试、发布，使得各业务项目只需关注本身业务，组件得到充分复用，目前组件化已成功运用到各个业务项目中。
组件化并非一蹴而就，而是一个持续的过程，比如：随着业务组件会变得很多，业务组件需要支持业务方按需加载，同时需要考虑组件的包体大小，不能因组件包体过大导致页面加载过慢；业务组件应该通过类似 Jenkins 工具统一发布，发布前应进行自动化测试，以完成很好的测试覆盖等等。
当然在实际开发工作中会有许多不理想的情况，比如一个小项目没有那么多重复的代码，比如设计团队不认可组件化等等，所以组件化需要考虑具体的业务场景，在这个前提下设计出符合我们自身的组件化系统才有必要。
也许你还想看
优化无止境，爱奇艺中后台 Web 应用性能优化实践
一切数据皆可配置：爱奇艺海外站的运营后台设计实践
扫一扫下方二维码，更多精彩内容陪伴你！