前言

近日，百无聊赖，上网游逛，在《2023 JavaScript Rising Stars》 上看到了一个令人匪夷所思的仓库 shadcn/ui，就一年那个 star 数啊，蹭蹭的上涨了 39500 颗星星，这星星数™甩我的王者不知道多少条街，虽然我是个星耀常驻玩家，但是也受不了这刺激啊。

说来就干，研究一下什么来头，居然以迅雷不及掩耳之势，偷偷发育成难以仰望之帝~

好家伙，看了源代码，原来是一个基于 Headless UI 组件库 radix-ui 的上层 React UI 组件库，心想 Headless UI 组件不是几年前才火起来的玩意嘛，怎么在前端怎么就有一席之地了呢？

看样子真是一代新人换旧人，一代技术一代新人，技术的日新月异也未免是个坏事 ~

一、Headless 的历史和背景

我相信很多同学对计算机界的 Headless 比较熟悉，因为 Headless 一词最初就是来源于 Headless Computer（无头计算机）也就是 Headless System（无头系统），维基百科的介绍为：

无头系统（Headless System）是指已配置为无须显示器（即“头”）、键盘和鼠标操作的计算机系统或设备。无头系统通常通过网络连接控制，但也有部分无头系统的设备需要通过RS-232串行连接进行设备的管理。服务器通常采用无头模式以降低运作成本。

后来慢慢的就有了 Headless Browser（无头浏览器）、Headless CMS, Headless BI 等等常见的 Headless 系列；

Headless UI

在 2017 年，一个在基于 React 的 高阶函数（HOC） 以及 复合组件（Compound Components） 研发的 downshift 诞生了，它的诞生无疑间接的促使了 Headless UI 的来临；

---

在 2018 年 6 月 22 日一篇受到 downshift 启发介绍 Headless User Interface Components 的文章应运而生，只是那时候的评判大多褒贬不一，有赞同博主的，也有质疑博主的；由此 Headless UI 一词正式被大家所认知

---

后来在 2018 年 10 月 26 日改变现有 React 和 Vue 格局的 《React Conf 2018》大会引入了现有屌爆了的 React Hooks 概念之后； Headless UI 概念才慢慢的被大家所接受。

---

因为在大家后知后觉中，其实发现 Headless UI 概念其实与 React Hooks 概念大同小异，只是差别在了一个更多的实现所有数据或交互的状态逻辑层，一个实现现有常见的 UI 库的数据或状态逻辑层，理解不了没关系，下面再详细介绍下；

但是那时国内其实对 Headless UI 这一概念认知还较少，因为在国内这个内卷的时代，大家更多关心的是 React Hooks。

---

就这样到了2020年，在国内社区有较高知名度和影响的 Tailwind Labs 团队 介绍的 Introducing Headless UI 中慢慢开始在国内社区崭露头角；

二、什么是 Headless UI

Headless UI 全称是 Headless User Interface （无头用户界面），是一种前端开发的方法论（亦或者是一种设计模式），其核心思想是将 用户界面（UI）的逻辑和交互行为 与 视觉表现（CSS 样式） 分离开来；

换句话说，Headless UI 提供了一种方式来构建只包含逻辑和功能的用户界面组件，而不依赖于特定的 CSS 样式框架或 UI 库。

具体而言，Headless UI 的组件通常是纯粹的 JavaScript（或其他编程语言）组件，它们包含了一些交互逻辑和状态管理，但没有任何与视觉样式相关的代码。

三、为什么需要 Headless UI？

众所周知，在传统的 UI 组件中，通常被拆分为两大部分：

• 外观样式（传统组件 UI 展示层）
• 逻辑部分（Headless UI部分）

外观样式负责展示元素标签与样式，而逻辑组件部分则负责处理数据逻辑、状态管理和用户交互等功能。

我们看图说话

传统 UI 组件框架

传统 UI 组件包含部分：

优势：

我相信在座的各位同学，都有用过现成的一些 UI 组件库，例如：Bootstrap 、Material UI、Ant Design、element-ui 等等，在其中，我们能看的出来，传统 UI 组件的优势主要有：

• 开箱即用： 字面意思，直接 install 就可以用了；
• 易学易用： 文档嘛，一看就懂，一用就废；
• 功能性全： 根据这么些年的发展，这些个开源组件库，几乎能遇到的 bug 都给整治了；
• 部分响应式： 这不 Bootstrap 就是一个很好的例子吗

限制：

那么用过的同学肯定也知道现成 UI 组件库的一些痛点，比如：

• 样式难以定制： 正所谓一个萝卜一个坑，一个公司一套样式，一个项目一套样式，那么这时候的劣势就无限被放大了；
• 耦合性高： 传统 UI 组件库通常将界面样式、数据逻辑和用户交互等功能耦合在一起，导致代码难以维护和扩展；
• 创意受限： 公司设计师根据现有传统 UI 组件库提供的一套固定组件和样式，他们想要拓展创意，都收到了很大的影响；
• 依赖过多： 一些传统 UI 组件库可能依赖于大量的第三方库和插件，增加了项目的复杂性和维护成本；

研发中实际场景的重现

1、需求第一期：

参与人员：前端 A、后端 A、设计师 A、产品 A

其中有一个功能要实现一个日期选择组件，下图是第一期的实现

你噼里啪啦一顿操作的实现了

那么现在需求迭代了

2、需求第二期：

参与人员：前端 A、后端 A、设计师 B、产品 B

这时候问题就来了，设计师 B 想把这个日期选择的样式改一下，改成如下：

那么此时阁下又该如何去面对呢？

• 魔改 ？？
• :deep 强制改 ？？
• !important ？？
• 重写自定义 ？？
• 和设计师沟通 ？？
• 沟通不过来打一顿 ？？
• 不解气，这破工谁爱打谁打

那么我们此时不妨换一种思路，试试用 Headless UI 解决看看？？

Headless UI 的解决方案

根据上述咱们已经知道了，普通的 Headless UI 组件包含：数据逻辑、状态逻辑、用户交互等等

其实 Headless UI 的一些拓展还可以包括 浏览器兼容性 和 无障碍访问等功能

用传统 UI 组件库实现一个 date 组件代码：

<template>
     <date> 切换 </date>
     // do something  此处省略 500 行
</template>

<script>
//  do something 此处省略 500 行
</script>

<style>
// do something 此处省略 500 行
</style>

能看到组件的逻辑与标签和样式都是高度耦合在一起的，很不利于拓展

我们看下 Headless UI 实现的组件，截取部分：

能看到 Headless UI 实现的组件简便了很多，完全没有所谓的样式集成在里面了，你想怎么改就怎么改；

说白了，就是 Headless UI 的出现就是为了解决传统 UI 组件框架的缺点，你不是要定制样式吗，现在我 ™ 连样式都不给你，全部由你自己来实现，爱咋滴咋滴，想怎么折腾就怎么折腾，无论多离谱的定制化都能实现。

四、Headless UI 的优势和特点

• 灵活性高： 因为 Headless UI 将组件的逻辑和样式分离，咱们可以根据项目的需要，想怎么玩就怎么玩，你说呢？
• 可定制： 样式都没了，我这不是想咋定制就定制了吗，你别说两个设计师，1 V 10 都不成问题，还担心啥呢？
• 轻量级： 只有逻辑了，那可不少了一大堆代码了；
• 测试友好： 写过单元测试的同学应该都知道，有样式组件和没样式组件的单元测试那就是一个天一个地；
• 无需学习新的样式框架： 我只看你的 API 不就行了，那样式有啥好关注的。

五、Headless UI 的应用场景

根据个人实际经验，我总结出来的一些实际应用场景：

1. 跨平台应用： 如果你司同个项目在多个平台上共存，那么此时的样式肯定都是不大一致的，那么现在 Headless UI 就可以发挥它的作用了；
2. 定制化界面： 如果你们项目需要高度定制样式和功能，我觉得这是一个很不错的选择；
3. 公司项目较多： 因为一个项目会存在很多个不同样式同逻辑的组件，所以在一个公司中，业务场景较大，以及项目较多，不失为一个很好的选择；

当然 Headless UI 也有缺点，并不适用于所有的项目，

• 如果你项目使用简单，对设计没有较大的要求，还是用现成的 UI 库比较合适，毕竟开箱即用；
• 如果公司大家的技术水平参差不齐，还是别瞎整了，还是用现成得吧；
• 切莫为了跟风而且瞎折腾技术，从实际出发

总结

上述只是给大家介绍了 Headless UI 理论部分，也就是所谓八股文吧；

但是Headless UI的设计模式还是很值得大家去参考学习的；

下面将会有 Headless UI 实战等其它部分：

感谢大家的支持，码字实在不易，其中如若有错误，望指出，如果您觉得文章不错，记得 点赞关注加收藏 哦 ~