目前主要关注的是维护群内的业务组件库，当然也包括我们将要扩充的区块、模板、解决方案等之后。本文档主要结合我以往的项目经验，简单介绍一下我对前端材质生态的理解。首先，在我看来，素材从复用的粒度上大致可以分为以下几种：组件；块;页面模板；基于场景的解决方案；成分。组件作为前端物料的最小单位，服务于各种业务系统。在使用上，组件可以以组件库/单体包的形式提供给业务系统，也可以按照一定的DSL作为UI原子（UI可视化构建系统）/逻辑原子（逻辑编排系统）服务于具体的构建系统规格）。从组件架构和组成的角度，组件可以分为单包多组件（组件库）和单包单组件。这里以antd为例：antd本身以组件库的形式以单包多组件的形式提供给开发者，antd底层的每个组件都依赖于react-component中的一个单包单组件.单包多组件形式的好处是组件更加聚合呈现给用户，组件之间的共同依赖可以更好的抽象和复用。对于用户来说，引用一个包就可以享受整个包的资源。但缺点是一个小小的改动也需要将整个组件库作为一个整体来承包。单包单组件形式的好处是组件自然解耦，组件独立发布。缺点是，由于每个组件在物理上是完全隔离的，所以需要抽取更多的基础依赖包，供公共依赖共享。如果单包组件存在链式依赖，每次发布对于组件开发者来说都是一个不小的挑战。当然也可以通过MonoRepo架构在一定程度上解决。另外，如果某个组件体积大，逻辑重，有一定的domain-specific复用场景，也可以以单组件包的形式单独提供，比如：富文本编辑器，视频播放器等。从功能的角度来看，我们的组件可以分为专注于视图和交互的视图组件和专注于业务逻辑的容器组件。ContainerComponents容器组件常用于聚合多个表现组件，承载一定的业务逻辑：请求接口、合并数据等。在容器组件的复用中，我们经常使用renderprops、HOC或者更细粒度的hooks来实现（视图组件也是如此）。视图组件视图组件按照业务场景的使用和功能的划分可以进一步分为UI组件和业务组件。UI组件首先是UI组件。从功能上来说，这类组件主要是作为页面上的最小单元，解决某类单点场景，或者说，这类组件就是在前端页面找联合对于特定类型的场景。比如Input、Select等，它们最大的优势就是极高的复用性和灵活的使用。但缺点也随之而来。解决单点场景的UI组件，需要结合大量的组件和业务逻辑来生产一个前端页面。UI组件一般是一个通用范式，可以满足业界大部分场景。业界经常将这些具有通用特性的UI组件以组件库的形式供开发者使用，例如AntD、ElementUI、Fusion等。针对特定场景和业务领域，有自己独特的设计语言或组件组合模式。对于迭代速度快、项目工程资产多的中后端团队来说，每个项目、每个团队在同一个业务领域下放一套组件资产，显然是一种人力浪费。组合范式可以以业务组件库的形式沉淀。比如我所属的广告投放区域有大量的人群、时间、区域选择组件，或者中后台常见的表单联动。这些组件往往是输入、选择等UI组件加上一定的业务交互逻辑和设计。规范，那么我们就可以将它们以业务组件和业务组件库的形式进行沉淀。综上所述，UI组件是为了满足大多数生产场景的通用范式而设计的，而业务组件是为了满足特定业务领域的通用范式而设计的。它们都是为了解决前端页面的单点场景而设计的。块组件维度可以满足大部分生产场景，但是对于固定模式的交互场景，单纯依赖组件还是需要大量重复组合的工作，所以我们使用块来解决某块内容的复用问题。在使用中，组件多由组件库或单包npm引入。但由于block的覆盖范围更广，如果以npm包的形式使用，用户将可以组合大量的props使用，使得复杂度从组件的拼接变为props的拼接.所以在区块维度上，我们提倡使用源码。传统组件库在使用中，消费者多半是选择组件后复制展示现场的demo，由于粒度问题，块的源代码会存在于多个文件中，消费者很容易粘贴代码看起来很麻烦，所以我们登陆了一个素材拉取工具（cli工具和vscode插件）。至此，在使用中，区块的生产者根据设计稿/交互稿生成区块源码，区块的消费者通过工具将区块源码插入到项目的指定位置，删除或删除根据自己的业务逻辑更新拉块。下块源代码。另外，为了更细粒度的使用，比如使用antd等UI组件库的demo粘贴功能，我们还提供了blocktreebyfile的可视化cv操作。在存储上，我选择将块材料存储在cdn而不是npm上。首先，由于源码的一次性使用特性，区块不需要强版本控制（虽然我也支持按版本存储），消费端不需要感知后续区块的升级。另外CDN的拉取在一定程度上也比npm包的安装快很多。另外，每次发布区块上传到cdn时，我们的依赖分析工具也会自动生成当前区块需要的依赖包和版本。拉取时，cli工具/vscode插件识别到要安装的block名称后，kernel会去cdn寻找@latest版本的block资源，下载到消费者指定的目标位置side（当然也支持指定版本号pull），block下载完成后，内核会根据block的依赖和目标项目的依赖做一次依赖diff，提醒消费者是否安装/更新材料依赖性。在展示站点和本地开发上，由于我们的block没有使用npm进行存储，所以我们沉积本地开发同步脚本，发布同步脚本，实现工程自动化，减少重复工作量。至此，一个完整的区块生产/消费环节大致如下图所示：在效率提升方面，由于采用了源码方式，区块的效率提升范围更多集中在初始化项目或者某个函数中在页面上单次使用，后续维护会像普通页面一样由开发者维护，不存在块更新。那么痛点也随之而来。源代码的使用使得区块的迭代和业务的升级变得无关紧要。当有整体UI升级场景时，需要同时修改块素材和业务方。页面模板模板比块粒度更粗。它关注的场景是一个有固定交互逻辑的页面。一个模板也可以由多个块、组件和源代码组成。例如：常见的中后台搜索列表页面、报表分析页面等。在使用上，页面模板和块的使用类似，甚至复杂场景下页面模板也可以算作块，这里不再赘述。另外，在展示站点，我们特别打造了标注素材的功能，用户可以通过该功能看到当前模板依赖了哪些素材资源，并可以进入当前素材的详情页。从另一个角度，用户还可以根据模板的材质标记，看到块组合的效果和实际使用场景。在效率提升方面，模板的粗粒度限制了它只能对某个页面进行快速初始化。它的缺点与块相似。基于场景的解决方案最后是基于场景的解决方案。场景化解决方案旨在让开发者基于页面模板、工程脚手架、数据管理、发布部署等能力，基于源码快速开发出固定场景的前端应用。例如：在中后台管理系统场景中，我们可以使用AntDesignPro快速实现一个中后台项目。我们也可以在微前端方案的基础上，封装一个具有良好隔离和应用划分的微前端工程模板。也可以是dumi、bisheng等专注于生产力工具静态站点展示的工程工具。可见场景化解决方案在项目层面提升了效率。它使用庞大而全面的项目模板，帮助开发者快速初始化一个前端工程项目。因此，其复用范围仅限于固定服务项目的项目初始化。结语最后总结一下：组件：解决单点问题UI组件：解决一般场景下的单点问题，复用率高，灵活；业务组件：解决固定业务场景下的单点问题，复用率高，灵活，但不如UI组件：块：解决页面中某块内容的制作，使用源码，复用率低于组件，使用一次；页面模板：解决页面级复用，源码使用，复用率低于block块，一次性页面初始化；场景化解决方案：解决项目级复用，工程化使用，复用率仅限于固定场景生产项目初始化；关于前端素材资产纬度的内容就分享到这里，后面我也会沉淀这篇文章专门讲解前端素材生态下的工程自动化。
