目前的主要精力是在維護組內的業務元件庫，當然也包括後續我們擴充套件的區塊、模版、解決方案等。這篇文件主要結合我過往的專案經歷，簡單介紹下我對於前端物料生態的理解。
首先在我看來，從複用的顆粒度上劃分物料大致為分下面幾種：
- 元件；
- 區塊；
- 頁面模版；
- 場景化解決方案；
元件
元件作為前端物料的最小單元服務於各個業務系統。在使用上，元件既可以以元件庫 / 單包的形式提供給業務系統使用，也可以按照一定的 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 元件：
- 區塊：解決頁面中某一個塊內容的生產，原始碼使用，複用率低於元件，一次使用；
- 頁面模版：解決頁面級別的複用，原始碼使用，複用率低於區塊，一次頁面初始化使用；
- 場景化解決方案：解決專案級別複用，工程使用，複用率僅限於固定場景生產專案初始化；
關於前端物料資產緯度的內容就分享到這裡，後面我也會沉澱一篇文章專門講解前端物料生態下的工程自動化。