说说「反混沌」：Fxxk Design

说说「反混沌」：Fxxk Design

就在前几天，集结很多业内大牛的某厂连续开源了好几个前端相关项目，其中两个是 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」的部分架构——

Petals 与 Kokiri

图中所示架构的思想在「聊聊前端 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」体系提供。