[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特性,每次的渲染都是独立的,每次渲染的状态其实都只是常量罢了。

深入本质

让我们看深入一下本质,看看 useStatere-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 可以模拟旧时代的三个生命周期:componentDidMountshouldComponentUpdatecomponentWillUnmount,相当于三个生命周期合并为一个 api。

所谓shouldComponentUpdate,其实就是去除deps依赖数组,如此一来这个副作用的 effectFn 会在首次渲染之后和每次重渲染之后执行,相当于模拟了 shouldComponentUpdate 这一生命周期,如下:

useEffect(() => {
  // xxx
});

而所谓componentDidMount,则是传入一个空数组作为依赖,因为当有 deps 数组时,里面 effectFn 是否执行取决于 deps 数组内的数据是否变化,空数组內无数据,所以对比自然也就无变化,使用如下:

useEffect(() => {
  // xxx
}, []);

componentWillUnmount,则是在effectFn中返回一个清除函数,如下:

useEffect(() => {
  // 执行副作用
  // ...
  return () => {
    // 清除上面的副作用
    // ...
  };
}, []);

此外我们应该始终遵循一个原则:那就是不要对 deps 依赖撒谎。否则会引发一系列 bug。当然编辑器的 linter 也不会允许我们这样做,这一点非常关键。

原理

effectFn 就是当依赖变化时执行的副作用函数,这里的副作用,并不是一个贬义词,而是一个中性词。

函数内部与外部发生的任何交互都算副作用,比如打印个日志、开启一个定时器,发一个请求,读取全局变量等等等等。

好,现在这个 effectFn 可以返回一个清理函数cleanUp,用于清除这个副作用。典型的清理函数,如:clearIntervalclearTimeout,如:

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(2222); // 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数组里面。

posted @ 2021-03-30 11:30  陌上兮月  阅读(1030)  评论(0编辑  收藏  举报