某天，集結很多業內大牛的某廠連續開源了好幾個前端相關項目，其中兩個是 UI 組件庫。嗬傢伙！同時來倆，到底是想讓人用哪個啊？存心想要逼死糾結星人的節奏？
那倆 UI 組件庫的名字裏都有「Design」，表明自己是「Design System」而不是普通的「UI Library」。這讓我想起了那段時間一波又一波出現的「元宇宙」公司。嗯～熟悉的味道。
不過，這也點了我一下——何不把我正在建設中與規劃要做的 design-to-code 相關的項目一併打包成「Fxxk Design」呢？這樣既有逼格又讓人能夠大概知道我的那些東西是要解決哪些方面問題的。我這土鱉黑鋼級直男碼農終於學會了「概念包裝」，真是謝謝它們了啊！
對我來説，那兩個 UI 組件庫幾乎沒什麼亮點，但各自又分別有一點引起了我的注意——其中一個提到的「Foundation + Adapter」模式和另一個將 UI 組件等單獨發包打造物料市場的做法——這些與我在做和要做的事情十分貼近。
業界現狀
在説「Fxxk Design」之前，先來梳理下當前流行 UI 組件庫的一些特點——
最直觀的就是，與某個技術棧進行了深度綁定，並以一整個 UI 組件集合的形式提供給使用者。人們在交流時所用的語言描述是「React/Vue 的 UI 組件庫 XXX」，而不是「XXX 組件」。
可以説，這是一種「單體架構」，如果某個 UI 組件新增了特性或修復了 bug，需要組件庫整體升級，想要以組件粒度進行升級是不可能的。並且，就算是在相同技術棧上，不同組件庫間的無縫遷移也是不存在的。
另外，那些 UI 組件庫自身限死了端的形態——桌面端 UI 組件庫、移動端 UI 組件庫。
當前流行的 UI 組件庫，普遍定製能力較差，主要體現在兩方面：沒有風格變量或粒度不夠，導致無法定製風格或定製很有限；行為的定製也是同理，同時也是它們限死端的形態的原因之一。
由於定製能力差，再加上上文所述情況，不具備打造物料市場的條件，從而形成不了以它們為中心的生態系統。
它們的設計在我看來大多不夠「原子」，不夠「純粹」——如 Input 組件把實質上不是同一個東西的通過 type 屬性去控制具體的展示形態；如 Button 組件擁有值為 primary、text 等的 type 這種與其自然特性毫無關聯的屬性——這樣的設計很容易讓一個 UI 組件在多方面顯得「臃腫」、「笨重」。
文檔也千篇一律地列 API、放 demo，幾乎不會去詳細地闡述某個 UI 組件適用於哪些場景，有什麼侷限性——缺少組件粒度的 UX/UI 設計模式等指導性內容。
還有一點比較「國內特色」——提供面向中後台場景的「Pro」。多數「Pro」是免費使用的，可就是有那麼幾個不僅質量不咋樣，還需要購買授權才能夠用。
Fxxk Design
如文章開頭所説，「Fxxk Design」是將以 design-to-code 為目標的相關項目進行打包的「概念」，就像一個專門用來裝書的箱子。
「Fxxk Design」不單要解決 design-to-code 相關問題，還是更大願景的一部分，因此該體系下的項目將採用分層、鬆耦合的架構作為基本原則。
下圖為目前「Fxxk Design」的部分架構——
圖中所示架構的思想在「聊聊前端 UI 組件」系列文章中已經説明，這裏不再贅述。可以看出，整體分為底層的 Petals 和上層的 Kokiri 這兩大部分。
建設中的
Petals 和 Kokiri 皆為正在建設中的項目，它們是文章《聊聊前端 UI 組件：組件體系》中所述思想的實踐——
Petals 作為 UI 組件的基礎設施、UI 組件的靈魂而存在，主要包含了「風格組件」（由 Sass 變量與 CSS 自定義屬性定義的主題風格變量）、「視覺組件」（CSS 規則集）和「無頭組件」（無 DOM 操作的純計算邏輯）等。
文中提到的「結構組件」實際上就是 React、Vue 等生成視圖結構的庫/框架與「視覺組件」和「無頭組件」等之間的連接器，屬於適配層——Kokiri 就是這麼一個角色，專門負責對接 Vue 及基於它的 UI 組件庫。
在 Kokiri 的內部又分為了兩層——把 Vue 與「視覺組件」和「無頭組件」等進行連接的 @kokiri/core；將 Petals 中定義的 API 之類適配到現有 UI 組件庫的 @kokiri/element、@kokiri/view-ui 等。
除了這些，由於現有 UI 組件庫中所提供的 UI 組件無法完全覆蓋 Petals 中定義的，因而又自己實現了一套 UI 組件——kokiri。
綜上所述，關於跨運行環境的問題，在該體系下目前有兩種適配方案：像 @kokiri/core 這種跨技術棧；再就像 @kokiri/element、@kokiri/view-ui 一樣跨組件庫。
也就是説，如果要支持新的技術棧或新的 UI 組件庫，只要像上面所説那樣做就好。
另外，Petals 中除了與 UI 組件直接相關的基礎設施，還集成了 Nicolas Gallagher 的 normalize.css 和 SUIT CSS 相關樣式，以及 Compass 的 function、mixin 等。
規劃中的
Petals 和 Kokiri 之類所起到的作用只能算是 UI 組件體系中的基本操作，要想對 design-to-code 產生更大價值，就得打造豐富的物料市場並與 UX/UI 設計環節打通。
物料市場中不僅有單獨的 UI 組件，還有 UI 組件集合、UI 組件庫適配器、主題風格等等。
規劃中要做的新版 Buds 的定位中就包括了對物料市場的支持這部分——UI 組件的開發、調試、打包、發佈等。
總結
與當前業界的普遍做法不太一樣，「Fxxk Design」追求的是原子化、鬆耦合的設計，這樣一來，很容易做到跨運行環境，如：技術棧、UI 組件庫等。
該體系下的 UI 組件都單獨發包，能夠以組件粒度獨立升級。
由於可定製性較強，主題風格的變換、桌面端與移動端兼容、物料市場的打造等都相對更容易些。
最後，「Fxxk Design」不提供所謂的「Pro」，對中後台場景的支持由「Future.js」體系提供。
本文其他閲讀地址：個人網站｜微信公眾號
