前端组件库

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 库的数据或状态逻辑层，

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

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

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

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

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

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

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

现成的一些 UI 组件库，例如：Bootstrap 、Material UI、Ant Design、element-ui 等等，在其中，我们能看的出来，传统 UI 组件的优势主要有：

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

限制：

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

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

Headless组件：

灵活性高： 因为 Headless UI 将组件的逻辑和样式分离，咱们可以根据项目的需要，想怎么玩就怎么玩，你说呢？

可定制： 样式都没了，我这不是想咋定制就定制了吗，你别说两个设计师，1 V 10 都不成问题，还担心啥呢？

轻量级： 只有逻辑了，那可不少了一大堆代码了；

测试友好： 写过单元测试的同学应该都知道，有样式组件和没样式组件的单元测试那就是一个天一个地；

无需学习新的样式框架： 我只看你的 API 不就行了，那样式有啥好关注的。

我总结出来的一些实际应用场景：

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

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

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