React Hooks 的使用限制有哪些？

站长

2022年12月05日 00:02 · 阅读数 50

在日常的工作或者面试中，我们都会用到React Hooks，那么在日常的开发中，使用React Hooks有哪些需要注意的点呢？今天我们就一起来探讨一下吧！

`Hooks` 的设计初衷

早在2016年，React 官方团队就开启了 React Future 的项目，他们试图探索未来方向，里面就提到了一个概念叫 Stateful Functions。

Stateful Functions 的目的就是通过引入 state 来拓宽函数组件的使用边界，但这个方案最终没有成功落地。

React 官方团队在过去使用 class 编写的组件数以万计，但是他们遇到了一些问题。

最常见的问题就是组件之间难以复用状态逻辑，可以通过高阶组件来解决，但是如果设计的场景更复杂，多级组件需要共享状态，那么就需要用到 Redux 或 Mobx 来解决了，因此最好能够考虑从 React 层提供 API 来解决。

其次就是 class 组件中的生命周期函数没能提供最佳的编程实践范式，例如：我们可以在 componentDidMount 中设置页面的标题、订阅聊天状态信息、获取用户信息、获取用户按钮权限信息等，当我们将这些业务逻辑都写在 componentDidMount 这个生命周期函数中时，就会使内容变得杂乱，缺乏专注性，而且往往还会对上下文(this)产生依赖。

如果你在 componentDidMount 中开启了一个定时器 setInterval，那么你就需要在 componentWillUnMount 中去 clearInterval，否则就很有可能因为定时器没有关闭，导致内存的泄漏。

开启定时器与关闭定时器并没有直接关联在一起，而是通过不同的生命周期函数去使用，这非常的反模式，也就导致 class 组件难以分解，并且到处都是状态逻辑。虽然我们可以通过 Redux 或者 Mobx 这些状态管理框架来处理类似的问题，但是使用它们是有一定的成本的。

既然这些问题大家都会遇到，那么是不是能够考虑由 React 提供相关的 API 来解决呢？

当然最初的 React 组件编写只能用类组件，而类本身就很容易令初学者，甚至是熟手犯错，还会给机器造成困扰。为什么还会给机器造成困扰呢？首先 this 问题首当其冲，在使用 this 的过程中，只要不注意 this 的指向，那么代码就会报错；其次还有一个关于 this 相关的问题就是用 bind 函数包裹一下来绑定事件，虽然现在已经通过了类属性方案，也可以使用 Babel 插件提前开发，但是整个提案仍旧是草案阶段，还不是很稳定；最后就是在类中难以做编译相关的优化。因此不光是人难以优化类，机器也难，这就有导致下一步的探索工作难以有新的进展，因此基于以上的原因，React 官方团队选择了以函数组件为基础进行相关设计。

`Hooks` 的方案原理

在最开始接触 Hook 时， React 官方给出的一个示例就是通过在函数中使用 useState 来返回当前组件的状态和更新状态的函数，代码如下图所示：

React Hooks 的使用限制有哪些？

我们可以看到上图中通过 useState 来进行状态的获取和修改，那么如果我们在 if 条件中调用 useState 会怎么样呢？这样做会造成数组的取值错误，因此不能在 React 的循环、条件或嵌套函数中调用 Hook，这里我们用数组来简化了 React 的描述，实际在 React 的源码中是通过链表来实现的。

在整体的设计结构中可以发现 React Hooks 的设计是贴近函数组件的，而在类组件方面，为了未来的优化探索， Hooks 直接就选择不支持，但是这并不意味着 class 组件和 Hook 组件不能混用，React 官方团队甚至还鼓励这两者进行混用，React 官方团队并不希望我们用 Hooks 去重写以前的 class 组件，那没有什么意义，只是徒增工作量。

`Hooks` 的使用限制

通过前面的描述，我们能够总结两点 React Hooks 的使用限制：

不要在 React 的循环、条件或嵌套函数中使用；
Hooks 只能在函数组件中使用，不支持类组件。

因为这些规则都是 React 的内在设计原理，因此不可能绕过这些限制的规则，但是我们可以在代码中禁止错误的使用方式。我们可以通过使用 ESLint 引入 eslint-plugin-react-hooks 这个插件，就可以完成自动化检查，这样在代码的编写中就能帮我们监测出使用错误的地方。