共计 2422 个字符，预计需要花费 7 分钟才能阅读完成。
某天，集结很多业内大牛的某厂间断开源了好几个前端相干我的项目，其中两个是 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」体系提供。
本文其余浏览地址：集体网站|微信公众号
