爱奇艺知识WEB前端组件化实践

组件化作为一种开发模式,其在代码复用,提高开发效率上的效果被广泛认可。组件化思想适用于移动端、Web前端、PC端、TV端等多种类型的客户端和前端开发

本文主要讲述爱奇艺知识 WEB 前端团队如何结合自身的业务特点,探索和实践了一套高效的前端组件化方案。

组件化:前端解耦和提效利器

前端业务发展过程中,代码体积会越来越大,业务的逻辑复杂程度也会随着迭代越来越高。

组件化的意义在于提效,交付的产物是可用的、直观的、可组合的业务形态。

目前行业内前端组件化按面向使用人群大致可分为3类:

面向运营人员:运营人员主要进行页面的创建、设计,组件类似乐高积木一样,拼凑起来,针对特殊的组件,可交给开发人员定制实现,实现一些偏静态或者偏固定功能(如抽奖、问答、支付等)的页面,各个大厂一般都有自己 Low Code 平台下类似的产品。

面向设计人员:设计人员主要参与页面设计,并直接将设计稿转换成前端代码,省去前端的开发过程,比如阿里的 imgcook,也可针对一些复杂逻辑,可交给开发人员进行二次开发。

面向开发人员:这也是最传统的开发模式,主要针对的是动态的页面,需要后端接口配合的场景,各个页面的组件通用,所以抽离出来公共组件供各个页面调用。

爱奇艺知识的组件化设计属于第三种,也即是面向开发人员而设计的。在开发层面,通过组件的复用,能够减少冗余代码、实现功能和业务逻辑的解耦,并且通过组件的拓展提高可拓展性、可维护性

业务场景:项目多且独立、又要保持产品一致性

具体到组件的拆分,目前在业内并没有统一的标准,需要结合具体的业务场景,因为不同场景下组件拆分的力度、程度可能都有所不同。

爱奇艺知识WEB前端组件化实践_第1张图片

爱奇艺知识 WEB 前端项目构成

从爱奇艺知识WEB前端项目构成可以看到,知识Web前端的项目很多,我们把项目按类型分开,每个分类下的项目都是独立的项目,完成其相关的业务功能,各项目是独立开发、独立部署的,并且项目间没有直接的业务关联。项目虽然多,但项目中都有业务相关的课程、讲师、店铺等实体,而这些实体的UI样式在各个项目中要基本保持一致,另外一些通用的UI元素,比如弹框、loading等也要保证风格一致,因此为了产品体验一致性,同时提升开发效率,提高代码复用性,Web前端需要进行组件抽离

在这里需要简单说明一下,我们Web端组件化思路和知识移动端团队在组件化的思路是不太一样的,移动端更多的是从业务和功能的纵向进行组件划分,也可以称之为模块化,每一个组件或模块既包括UI又包括业务逻辑,比如播放器组件播控播放控制和UI样式,分享组件包括分享功能和弹窗,支付组件包括支付流程和收银台支付结果页;而Web前端的组件化更偏重UI层面,逻辑更多的是放在页面中,这也符合Web开发的特点,UI元素复用性更高

感兴趣的同学可以了解一下移动端组件化的设计思路,传送门在这里:爱奇艺知识移动端组件化探索和实践。

根据上述背景,知识Web前端进行了相应的组件化建设,目标如下:

1. 代码复用,提升开发效率

根据业务特点,横向和纵向划分组件,以组件为单位承接业务需求。虽然以UI组件为主,但对于相对独立的功能,也进行了纵向的组件抽取。

2. 组件独立开发维护,与各项目解耦

组件单独开发、调试、发布,供业务方调用,业务方只需专注业务本身。

3. 更方便的组件调用,更合理的路由跳转

组件调用需明确输入、输出参数,并对参数进行校验并给出合理错误提示;当各项目引用业务组件 涉及到跳转时,组件库自动决定是项目内(前端路由)跳转还是项目外(location.href)跳转。

4. 组件文档化,支持在线调试,降低组件使用门槛

组件库需要有完善的使用说明文档,支持在线调试,使业务方更加容易、便捷的使用。

整体设计

任何工具的设计都需要从实际的业务场景出发,回到我们的场景下,需要考虑如何管理项目间所依赖的公共组件资源变得非常重要,组件的设计既要符合业务方使用的便利性,同时也要满足组件自身开发的可维护性、可扩展性

我们认为,组件化的关键在于组件的分层以及拆分,明确组件的层级以及对层级的定义对于组件化系统至关重要。下面是基于我们自身的业务,我们将组件进行如下分层(图示):

爱奇艺知识WEB前端组件化实践_第2张图片

为了更好的理解,我们将层级之间的关系进行如下展示(图示):

爱奇艺知识WEB前端组件化实践_第3张图片

由于 Card 组件由多个 Item 组件组成,所以 Card 组件与 Item 组件的关系如下:

爱奇艺知识WEB前端组件化实践_第4张图片

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 组件。

爱奇艺知识WEB前端组件化实践_第5张图片

UI 实现

在具体的 UI 实现方面,我们拿下图中我们的业务 UI 组件库内常用的两个Item举例:课程列表 Item、课程宫格 Item

爱奇艺知识WEB前端组件化实践_第6张图片

爱奇艺知识WEB前端组件化实践_第7张图片

不难发现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 组件在线调试,更能直观的表达组件样式与交互,增强了组件的易用性。

爱奇艺知识WEB前端组件化实践_第8张图片

总结

前端组件库一般是放到公司的私有仓库上,通过 npm 进行维护的,使用方需要 引用并打包到自己的项目内才能使用。随着 webpack5 module federation 的流行,也可以将组件当作微模块单独发布,各使用方可通过动态 load module 的方式进行引用

由此也可以看到前端组件化的优势:可以很大程度上降低系统各个功能的耦合性,这对前端工程化及降低代码的维护成本来说,是有很大的好处的。

爱奇艺知识 WEB 前端组件库经过不断的完善和迭代,基本实现了组件化的全部目标,组件通过独立开发、测试、发布,使得各业务项目只需关注本身业务,组件得到充分复用,目前组件化已成功运用到各个业务项目中。

组件化并非一蹴而就,而是一个持续的过程,比如:随着业务组件会变得很多,业务组件需要支持业务方按需加载,同时需要考虑组件的包体大小,不能因组件包体过大导致页面加载过慢;业务组件应该通过类似 Jenkins 工具统一发布,发布前应进行自动化测试,以完成很好的测试覆盖等等。

当然在实际开发工作中会有许多不理想的情况,比如一个小项目没有那么多重复的代码,比如设计团队不认可组件化等等,所以组件化需要考虑具体的业务场景,在这个前提下设计出符合我们自身的组件化系统才有必要。

也许你还想看

优化无止境,爱奇艺中后台 Web 应用性能优化实践

一切数据皆可配置:爱奇艺海外站的运营后台设计实践

 扫一扫下方二维码,更多精彩内容陪伴你!

你可能感兴趣的:(人工智能,java,javascript,html,编程语言)