目前的次要精力是在保护组内的业务组件库，当然也包含后续咱们扩大的区块、模版、解决方案等。这篇文档次要联合我过往的我的项目经验，简略介绍下我对于前端物料生态的了解。

首先在我看来，从复用的颗粒度上划分物料大抵为分上面几种：

• 组件；
• 区块；
• 页面模版；
• 场景化解决方案；

组件

组件作为前端物料的最小单元服务于各个业务零碎。在应用上，组件既能够以组件库 / 单包的模式提供给业务零碎应用，也能够依照肯定的 DSL 规约服务于特定的搭建零碎作为 UI 原子（UI 可视化搭建零碎） / 逻辑原子（逻辑编排零碎）。

从组件架构和组成模式上看，组件能够分为单包多组件（组件库）和单包单组件和两种。

这里以 antd 举例：antd 自身作为组件库以单包多组件的模式提供给开发者，而 antd 底层的每个组件又依赖于 react-component 中的一个单包单组件。

单包多组件模式的益处在于组件更聚合的出现给使用者，并且组件间的公共依赖也能够更好的形象复用，对于应用方来说引一个包就能够享受整包的资源。然而毛病在于某一个小小的改变也须要整个组件库整体发包。

单包单组件模式的益处在于组件见人造解耦，组件见独立公布。而毛病在于，因为每一个组件都齐全物理隔离，那么对于公共依赖就须要抽离更多的根底依赖包来共享。如果单包组件存在链式依赖，对于组件开发者来说每一次公布也是不小的挑战，当然，也能够通过 MonoRepo 架构来肯定水平解决。此外，如果某一个组件体积较大、逻辑较重、具备某个畛域特定的复用场景，也是能够独自以单组件包的模式提供，例如：富文本编辑器、视频播放器等。

从性能上看，咱们的组件又能够划分为关注视图和交互的视图型组件和关注业务逻辑的容器型组件。

容器组件

容器型组件往往用于聚合多个展现型组件，并承载肯定的业务逻辑：申请接口、合并数据等等。而在容器组件的复用上，咱们经常采纳 render props、HOC 或者粒度更细的 hooks 来实现（视图组件也如此）。

视图组件

视图组件从业务场景的应用以及性能的划分上又进一步的能够分为 UI 组件和业务组件。

UI 组件

首先是 UI 组件，从性能上来讲这类组件次要是作为页面上的最小单元来解决某一类单点场景，或者说，这类组件是针对某类场景在前端页面中找并集，例如 Input 、Select 等，他们最大的长处就是复用度极高、应用灵便。然而有余也与之而来，解决单点场景的 UI 组件须要组合大量的组件和业务逻辑能力生产出一个前端页面。

UI 组件个别是可能满足业界绝大部分场景的通用范式，业界往往是将这些具备通用个性的 UI 组件以组件库的模式给开发者应用，例如 AntD、ElementUI、Fusion 等。

业务组件

尽管说 UI 组件库曾经可能满足绝大部分的设计、生产需要，但对于特定的场景、业务域来说往往有着本人独特的设计语言或是组件的组合模式。对于迭代速度快、我的项目工程资产多的中后盾团队来说，每一个我的项目、团队都去积淀一套雷同业务域的组件资产显然是节约人力的行为，那么此时对于以后业务域的这些组件的组合范式便能够以业务组件库的模式积淀下来。

例如，我目前所属的广告投放领存在大量的人群、工夫、区域的圈选组件，或者说中后盾常见的表单联动，这些组件往往就是 input、select 等 UI 组件加上肯定的业务交互逻辑和设计规范，那么咱们便能够将他们以业务组件和业务组件库的模式积淀下来。

总结起来，UI 组件是为了满足大部分生产场景的通用范式，而业务组件是为了满足某一特定业务畛域的通用范式，他们都是为了解决前端页面某一单点场景。

区块

组件维度曾经可能满足大部分的生产场景了，然而对于固定模式的交互场景，单靠组件仍是须要大量的反复组合工作，因而咱们通过区块来解决某一块内容的复用问题。

在应用上，组件多为组件库或单包的 npm 引入。而区块因为覆盖范围更广，如果通过 npm 包的模式应用就会让应用方组合大量的 props 来应用，使得复杂度从组件的拼接变为了 props 的拼接。因而在区块维度上，咱们更提倡应用源码模式应用。在传统的组件库的应用上，消费者多通过抉择组件后复制展现站点的 demo 来应用，而区块因为粒度的问题源码会以多个文件的模式存在，这样对于消费者来说粘贴代码就显得繁琐，因而咱们落地了物料拉取工具（cli 工具以及 vscode 插件）。

到此，在应用上，区块的生产者依照设计稿 / 交互稿生产区块源码，区块的消费者通过工具将区块源码插入到我的项目指定地位，并依照本人的业务逻辑删除或更新拉下来的区块源码。此外，对于更细粒度的应用，例如用惯了诸如 antd 等 UI 组件库的 demo 粘贴性能，咱们也提供区块树按文件的可视化 cv 操作。

在存储上，我抉择将区块物料存储在 cdn 上而不是 npm 上。首先，区块因为源码的一次应用的特色，使得区块并不需要很强的版本控制（尽管我也反对了按版本存储），生产侧也无需感知后续区块的降级。此外，cdn 的拉取在肯定水平上也比 npm 包的装置快的多。此外，在区块每次发版上传 cdn 的同时，咱们的依赖剖析工具也会主动生成以后区块所需的依赖包及版本。

在拉取上，cli 工具 / vscode 插件辨认到待装置的区块名后，内核会去 cdn 上查找 @latest 版本的区块资源并下载到生产侧指定的指标地位（当然也反对依照指定版本号拉取），区块下载结束后，内核会依据区块的依赖以及指标我的项目的依赖做依赖 diff ，从而揭示消费者是否装置/更新物料依赖。

在展现站点以及本地开发上，因为咱们的区块在存储上没有应用 npm ，因而咱们积淀了本地开发同步脚本以及公布同步脚本来实现工程自动化从而缩小反复工作量。

到此，一个残缺的区块生产/生产链路大抵如下图所示：

在提效上，因为应用了源码形式援用，区块聚焦的提效范畴更多在初始化我的项目或者页面上某块性能的单次应用，之后的保护都将和一般页面一样由开发者来保护，不存在区块更新的说法。那么痛点也与之而来，源码形式的应用使得区块的迭代和业务的降级不会有关联性，当呈现整体性 UI 降级的场景会使得区块物料和业务方同时须要批改。

页面模版

模版绝对于区块粒度更粗一些，他所聚焦的场景是具备固定交互逻辑的页面，一个模版又能够由多个区块、组件以及源码组成，例如：常见的中后盾搜寻列表页、报表剖析页面等等。

在应用上，页面模版和区块的应用大同小异，甚至页面模版也能够算做简单场景下的区块，因而这里就不过多的赘述了。此外，在展现站点上，咱们专门做了一个标记物料的性能，用户能够通过该性能看到以后的模版依赖了那些物料资源，并能够返回以后物料的详情页。换个角度来说，用户也能够依据模版的物料标记看到区块组合的成果以及理论的应用场景。

在提效上，模版的粗颗粒度也就限度了它仅固定在了某个页面的疾速初始化下面。并且他方面的弊病也都和区块相似。

场景化解决方案

最初就是场景化解决方案，场景化解决方案旨在基于页面模版、工程脚手架、数据管理、公布部署等能力让开发者疾速基于源码开发具备固定场景的前端利用，

例如：
在中后盾管理系统的场景下，咱们能够应用 Ant Design Pro 来疾速落地一个中后盾我的项目。

咱们也能够基于微前端解决方案来包装一个具备良好隔离、利用分治的微前端工程模版。

也能够是像 dumi、bisheng 这样专一于生产力工具动态站点展现的工程工具。

能够看到，场景化解决方案是我的项目层面的提效，他利用大而全的我的项目模版帮忙开发者疾速初始化一个前端工程项目。因而他的复用范畴仅限在固定业务我的项目的工程初始化。

结语

最初总结一下：

• 组件：解决单点问题

  • UI 组件：解决通用场景下的单点问题，复用率高、灵便；
  • 业务组件：解决固定业务场景下的单点问题，复用率高、灵便，但不如 UI 组件：
• 区块：解决页面中某一个块内容的生产，源码应用，复用率低于组件，一次应用；
• 页面模版：解决页面级别的复用，源码应用，复用率低于区块，一次页面初始化应用；
• 场景化解决方案：解决我的项目级别复用，工程应用，复用率仅限于固定场景生产我的项目初始化；

对于前端物料资产纬度的内容就分享到这里，前面我也会积淀一篇文章专门解说前端物料生态下的工程自动化。