与 React 一起使用的最佳 UI 库是什么？
headless组件。
构建一个在所有浏览器中运行良好且可访问的良好自动完成功能可能需要几个月的时间。Headless UI 的组件在多种浏览器、平台和设备上都经过了很好的测试，并且可以处无法或不想处理的边缘情况：焦点管理、键盘导航、事件侦听器、可访问性属性、有效标记和屏幕阅读器支持等内容。
有几个流行的库：
- Radix UI：我最喜欢的。经过良好测试，可访问，并且拥有我见过的最好的组件 API 之一。它在使用 React 测试库测试它的组件时确实存在一些问题，并且不能很好地支持 IE。
- Reach UI：非常好且可靠，来自 react-router 和 Remix 的作者。组件不多，但涵盖了大多数用例。
- Headless UI：少量组件。经过良好测试，与 Tailwind CSS 搭配使用效果最佳。唯一的缺点是改变组件的功能和行为并不容易。
- Downshift：Kent C. Dodds 着。专注于自动完成、选择、组合框和多组合框组件。经过良好测试，可访问，并让您完全控制样式和功能。我为我们的组合框和自动完成组件选择了它，并从它们的实现中学到了很多东西。
- React-aria：由 Adobe 提供。我不太了解它，但它看起来很有趣。
- Reakit
- Ariakit
虽然这些是大型库，但也有许多单组件包。那些只关注一种类型的组件：无头模式、无头分页、无头单选按钮等，如react-table
在样式方面，无头组件适用于任何样式解决方案。如果您喜欢 Tailwind CSS，只需在标记上使用他们的类。如果 CSS-in-JS 是你的菜——你可以使用 styled-components、Emotion、vanilla-extract 或 Stitches 轻松地为它们设置样式。您不必使用 UI 库自己的自定义机制，这些机制通常很复杂，并且经常与库的特定实现耦合。
使用 Headless 组件库的缺点
- 更多的控制权，但也有更多的责任——无头组件给了我们更多的控制权，但这伴随着我们需要在此过程中做出更多决策的权衡。由于无头组件通常只负责可访问性和功能性，我们仍然需要自己实现样式和大部分渲染逻辑。在使用它们时，我们甚至必须做出更多的用户体验决策，因为他们对此不是很固执。
- 社区——MUI、Bootstrap 或 Ant Design 等 UI 库背后都有大型社区。你总是可以在他们的 Github 问题页面上找到问题的解决方案，并且定期发布错误修复。虽然无头库也得到了强大社区的支持，但它们并不像主要的 UI 库那样大或活跃。
什么时候应该青睐UI库而不是Headless 组件？
在写这篇文章的时候，我想找到一些使用无头组件的缺点，我的第一个想法是，如果你需要非常快速地发布产品，使用headless而不是UI库可能会阻碍你。毕竟，从UI库中渲染一个自动完成功能是很简单和直观的，我们只需要渲染一个<Autocomplete />，给它传递一些道具就可以了。但从我使用无头组件的经验来看，使用无头库实现同样的组件并不会花费更多的时间，而且从长远来看会给你带来更多。
因此，我目前对这个问题的回答是，如果我知道我正在建立一个具有独特功能和定制设计的设计系统，我肯定会选择无头组件。如果我觉得我可以满足大部分的要求而不需要花太多精力去定制它的组件，我可能会选择一个UI库。
在我的特定用例中，我需要支持对我们的产品来说非常独特的功能和设计，用UI库来实现这些功能是不值得的。