[React Hooks长文总结系列一]初出茅庐，状态与反作用

写在开头

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 钩子读取到错误的状态值。

useSate，状态保存之处

用法

const [count, setCount] = useState(0);

原理

首先，useState 会生成一个状态和修改状态的函数。这个状态会保存在函数式组件外面，每次重渲染时，这一次渲染都会去外面把这个状态钩回来，读取成常量并写进该次渲染中。

经过调用修改状态的函数，会触发重渲染。到这里咱们总结：props 的改变和 setState 的调用，都会触发 re-render。

因为每次渲染都是独立的，因此每次渲染都会读到一个独立的状态值，这个状态值，就是经过钩子钩到的 state 并读取到的常量。

这就是所谓的capture value特性，每次的渲染都是独立的，每次渲染的状态其实都只是常量罢了。

深刻本质

让咱们看深刻一下本质，看看 useState 和 re-render 到底如何关联起来：

1. 函数式组件初次渲染，一个个的 useState 依次执行，生成hooks链表，里面记录了每一个 state 的初始值和对应的 setter 函数
2. 这个链表会挂在这个函数式组件的外面，能够被 useState 或相应 setter 访问
3. 当某个时刻调用了 setSetter，将会直接改变这个hooks链表
4. hooks链表其实就是这个函数式组件的状态表，它的改变等效于状态改变，会引发函数式组件重渲染
5. 这个函数式组件重渲染，执行到 useState 时，由于初次执行已经挂载过一个 hooks 链表了，这个时候就会直接读取链表的相应值

这也就是为何叫useState，而不是createState。

useRef，DOM访问与外部状态保存

useRef有啥用

useRef主要有两个做用：

• 用来访问DOM；
• 用来保存变量到当前函数式组件外部。

访问DOM

咱们先来看看前者怎么用吧：

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对象保存在函数式组件外部，这样的好处在于：

1. 独立于capture value以外存储，不用担忧得到过期变量的问题；
2. 能够同步修改状态。

咱们试验以下：

const numRef = useRef(0);

const increaseNum = () => {
    numRef.current += 1;
    console.log(numRef.current); // 能获取最新值
}

可是要注意⚠️：因为引用没变，上述操做并不会引发函数式组件的重渲染。 这是一个很容易引发错误的地方！

useEffect，生命周期与观察者

用法及建议

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数组里面。