全新的 React 组件设计理念 Headless UI

其实，最早接触 Headless UI 是在去年，碰巧看到了一个非常前沿且优秀的组件库 ---- Chakra UI，这个组件库本身就是 Headless UI 的实践者，同时也是 CSS-IN-JS 的集大成者。

我当时看过之后，就对该理念产生了很大的兴趣，同时工作中也正好有机会实践（着手公司开源组件库大版本重构），因此对该理念也有一定的实践经验。

那么今天，也是想和大家分享介绍下这项还算前沿的技术，另一方面是也算是个人的一份技术总结，这里也希望感兴趣的小伙伴可以在评论区探讨。

契机：React Hooks 的诞生

React Hooks 可以说是 Headless UI 得以实现的基石，为什么这么说，这里我们首先聊聊 React Hooks。

React Hooks 是什么

我们都知道，React Hooks 是在 V16.8 版本诞生了，是它让我们的函数组件真正拥有了状态。如下图，我们以数字累加这个功能举例，可以看到对于同样的功能，React Hooks 的写法相对于过去类组件的写法从代码上会减少一丢丢。

但仅仅是因为如此才支持它吗？

我们要知道，在 React v16.8 之前，一般情况下，普通的 UI 渲染直接使用函数组件就好，需要使用 state 或者其他副作用之类功能时，才会使用类组件。

两者分工也算合理，那么 hooks 的诞生又是为何？仅仅是为函数组件赋能吗？从使用者的角度来说，这显然说不过去，徒增了学习成本不说，还多了一个纠结选项（函数组件 vs 类组件）。

React Hooks 的意义

所以，事情并没有那么简单。我们可以推断，对于 hooks 它肯定解决一些“类组件存在的不足或痛点”，这里就不卖关子，罗列 2 点：

1、状态逻辑在组件之间难以复用

在过去，状态逻辑的复用往往会采用高阶组件来实现。但劣势也非常明显，需要在原来的组件外再包裹一层父容器。 导致层级冗余，甚至嵌套地狱，引来了很多吐槽点：

• 增强调试的难度
• 拉低运行的效率

相信使用 Redux 的同学都知道，为了快速状态管理到组件的注入，会使用 connect 对组件进行包裹，但是随着项目迭代，打开 DevTools 查看时发现 DOM 往往臃肿不堪。

2、复杂组件变得难以理解和维护

复杂组件本身就很复杂，但是类组件让其变得更加难以理解和维护。比如：在一个生命周期函数中往往存在不相干的逻辑混杂在一起，或者一组相干的逻辑分散在不同的生命周期函数中，这里分别举个例子：

• 在 componentWillReceiveProps 中往往写入不相干 props 更新渲染的判断逻辑，对于一次更新，往往会多出一些无效的执行，拉低执行效率
• 在 componentDidMount 中注册事件，在 componentWillUnmount 中卸载该事件，往往容易忘记甚至写出 bug。

长此以往我们的代码只会变得糟糕难懂。