React Hooks在我的上一个项目中得到了充分的使用，对于这个项目来说，我们跳过传统的类组件直接过渡到函数组件，确实是一个不小的挑战。在项目开发过程中也发现项目中的其他小伙伴（包括我自己）有时候会存在使用不当的情况，因此对官方的几个钩子函数做一个较为全面的总结。
为什么会出现函数式组件，因为传统的类组件确实有不少缺点：
this 指向有点绕mixin，很容易带来数据来源指向不清楚的问题我们知道，在过去，函数式组件被称作“傻瓜组件”，因为它并不具有自身的状态，通常被用来做一些渲染视图的工作，即UI = render(props)。这是一个纯粹的输入输出模型，无任何副作用。但是React Hooks的出现，让函数式组件拥有自身的状态成为了可能。
函数式组件在运行过程中会被调用很多次，假如我们将状态保存在函数体里面，毫无疑问是不可行的。因为函数是一种“用完即销毁”的东西。
这正是是Hooks所做的事情：将一个函数组件的状态保存在函数外面。准确来说，是这个函数组件对应的Hooks链表。当函数式组件需要用到该状态的时候，通过Hooks这一钩子将状态从函数体外部“钩进来”。
函数式组件的生命周期可以分为以下三部分：
初次渲染（first-render） ---> 重渲染 (re-render) ---> 销毁（destroy）
当我们第一次使用函数式组件的时候，会触发初次渲染（first-render）；若其 props 改变，就会调用该 render 函数，触发重渲染(re-render)。
每一次的渲染，都是独立的。这正是函数式组件的美妙之处。
那么react如何决定要不要调用 render 函数来更新 UI 视图呢？这取决于data有没有更新。从整个组件树来看，data指的是整个组件的state；从具体到某个功能组件来看，data也可以被认为是props和自身state的结合体。
render 的执行取决于 data 变化，而 data 中的 state 数据是保存在链表中的。
链表的特性是啥？就是每个元素都有一个
next指针指向下一个元素，一环扣一环关联起来。所以为什么 hooks 不能用在条件判断/循环/嵌套中，因为这些都不能保证每次渲染时读取 hooks 链表的顺序是完全一致的。尤其对于状态读取来说，读取顺序和初次渲染链表记录的顺序不一致，会直接导致一些useState钩子读取到错误的状态值。
const [count, setCount] = useState(0);
首先，useState 会生成一个状态和修改状态的函数。这个状态会保存在函数式组件外面，每次重渲染时，这一次渲染都会去外面把这个状态钩回来，读取成常量并写进该次渲染中。
通过调用修改状态的函数，会触发重渲染。到这里我们总结：props 的改变和 setState 的调用，都会触发 re-render。
由于每次渲染都是独立的，所以每次渲染都会读到一个独立的状态值，这个状态值，就是通过钩子钩到的 state 并读取到的常量。
这就是所谓的capture value特性，每次的渲染都是独立的，每次渲染的状态其实都只是常量罢了。
让我们看深入一下本质，看看 useState 和 re-render 到底如何关联起来：
useState 依次执行，生成hooks链表，里面记录了每个 state 的初始值和对应的 setter 函数useState 或相应 setter 访问setSetter，将会直接改变这个hooks链表useState 时，因为初次执行已经挂载过一个 hooks 链表了，这个时候就会直接读取链表的相应值这也就是为什么叫useState，而不是createState。
useRef主要有两个作用：
我们先来看看前者怎么用吧：
const inputRef = useRef(null);
const handleClick = () => {
inputRef.current?.focus();
}
return (
<input ref={inputRef} />
<button onClick={handleClick}>点击</button>
)
这样就可以方便地访问DOM节点。
前面我们提到，useState可以方便地保存状态值，但是由于函数式组件的capture value特性，使得我们并不能以一种比较方便的形式获取到更改后的状态值。
const [num, setNum] = useState(0);
const increaseNum = () => {
setNum(prev => prev + 1);
console.log(num); // 打印的仍然是旧值，因为num在这一帧被常量化了
}
而useRef将会创建一个ref对象，并把这个ref对象保存在函数式组件外部，这样的好处在于：
capture value之外存储，不用担心获得过时变量的问题；我们试验如下：
const numRef = useRef(0);
const increaseNum = () => {
numRef.current += 1;
console.log(numRef.current); // 能获取最新值
}
但是要注意⚠️：由于引用没变，上述操作并不会引起函数式组件的重渲染。 这是一个很容易引起错误的地方！
useEffect 的模型十分之简洁，如下：
useEffect(effectFn, deps);
useEffect 可以模拟旧时代的三个生命周期：componentDidMount、shouldComponentUpdate、componentWillUnmount，相当于三个生命周期合并为一个 api。
所谓shouldComponentUpdate，其实就是去除deps依赖数组，如此一来这个副作用的 effectFn 会在首次渲染之后和每次重渲染之后执行，相当于模拟了 shouldComponentUpdate 这一生命周期，如下：
useEffect(() => {
// xxx
});
而所谓componentDidMount，则是传入一个空数组作为依赖，因为当有 deps 数组时，里面 effectFn 是否执行取决于 deps 数组内的数据是否变化，空数组內无数据，所以对比自然也就无变化，使用如下：
useEffect(() => {
// xxx
}, []);
而componentWillUnmount，则是在effectFn中返回一个清除函数，如下：
useEffect(() => {
// 执行副作用
// ...
return () => {
// 清除上面的副作用
// ...
};
}, []);
此外我们应该始终遵循一个原则：那就是不要对 deps 依赖撒谎。否则会引发一系列 bug。当然编辑器的 linter 也不会允许我们这样做，这一点非常关键。
effectFn 就是当依赖变化时执行的副作用函数，这里的副作用，并不是一个贬义词，而是一个中性词。
函数内部与外部发生的任何交互都算副作用，比如打印个日志、开启一个定时器，发一个请求，读取全局变量等等等等。
好，现在这个 effectFn 可以返回一个清理函数cleanUp，用于清除这个副作用。典型的清理函数，如：clearInterval、clearTimeout，如：
useEffect(() => {
const timer = setTimeout(() => console.log("over"), 1000);
return () => clearTimout(timer);
});
useEffect 其实是每次渲染完成后都会执行，但是 effectFn 是否执行，就要看依赖有没有变化了。执行 useEffect 的时候，会拿这次渲染的依赖跟上次渲染的对应依赖对比，如果没变化，就不执行 effectFn，如果有变化，才执行 effectFn。
如果连依赖都没有，那 react 就认为每次都有变化，每次运行 useEffect 必运行 effectFn。
useEffect 有典型的三大特点：
effectFn 之前，要把前一次运行 effectFn 遗留的cleanUp函数执行掉（如果有的话）effectFn 遗留的 cleanUp 函数执行掉。deps 数组里面的各个依赖与上次的依赖是否相同，需要通过Object.is来比较，比如：
Object.is(22, 22); // true
Object.is([], []); // false
这样就会有一个隐患，当 deps 数组里面的子元素为引用类型的时候，每次对比都会是false，从而执行effectFn。因为 Object.is 对比引用类型的时候，比较的是两个指针是否指向堆内存中的同一个地址。
useEffect 的执行机制，是在初次渲染时，执行到 useEffect 就将内部的 effectFn 放到两个地方：一个是 hooks 链表中，另外一个则是EffectList 队列中。在渲染完成后，会依次执行 EffectList 里面的 effectFn 集合。
所以，说白了，要不要 re-render，完全取决于链表里面的东西有没有变化。
不同于 vue 里面有async mounted，在 useEffect 里面的 effectFn，应该始终坚持一个原则：要么不返回，要么返回一个 cleanUp 清除函数。像下面这样写是不行的：
// 错误的用法❌
useEffect(async () => {
const response = await fetch("...");
// ...
});
另外我们很容易发现：我们并不需要把 useState 返回的第二个 Setter 函数作为useEffect 的依赖。实际上，React 内部已经对 Setter 函数做了 Memoization 处理，因此每次渲染拿到的 Setter 函数都是完全一样的，不需要把这个Setter函数放到deps数组里面。
