2022 react hooks 看这一篇就够了

·  阅读 1113

author 张向强

马上2022了,才开始说hooks,是不是有点晚?

不晚,不晚,总有新的小友,对它不那么熟悉,那这一篇从零开始,简洁有力的文章一定会很有帮助。

理论指导实践,有了理论依据我们才能跑的飞快,为了不误人子弟,我又重读了一遍官方文档(冗长而琐碎需要耐心的文档),所以文内最重要的理论依据会来源于官方文档摘抄(我会标识出来),请放心食用。

我希望你最好有一点react基础,一点点就够了,差不多就是能用react画个页面,然后知道一些生命周期的程度。

好了,闲话少说,我们开始。

Hooks 出现的背景

官方是这么介绍hooks的,Hook 是 React 16.8 的新增特性,它可以让你在不编写 class 的情况下使用 state 以及其他的 React 特性。

意思就是,hooks让你可以写函数组件,让函数组件的能力像类组件一样强大。

它出现的原因,简单来说有这么三个原因(官方写的有点绕,我用人话说一遍):

  1. 是在类组件之间复用状态逻辑很难(类组件之前一般使用render props和高阶组件的方式来复用逻辑)。Hook 使你在无需修改组件结构的情况下复用状态逻辑

  2. 复杂的类组件会变的很难理解。比如,很多时候相互关联的逻辑要同时写在componentDidMount,componentDidUpdate,componentWillUnmount几个生命周期中,逻辑一旦复杂起来维护就很麻烦。再比如,我常常会在一个生命周期里写很多不相互关联的逻辑。 我们希望的是,相关的逻辑写一起,不相关的就分开写。但是之前我们只能写在react暴露的生命周期里,业务逻辑一旦堆起来,就变的又杂糅又分散,这也是无奈之举。为了解决这个问题,Hook 将组件中相互关联的部分拆分成更小的函数,(也就是相关的逻辑可以写在同一个hook里),而并非强制按照生命周期划分。

  3. Class 难以理解。一个是要熟悉js里的this的指向,类里经常要用到,另一个是class 不容易优化。

hooks 的使用原则

只能在函数最外层调用 Hook。不要在循环、条件判断或者子函数中调用;

只能在 React 的函数组件中调用 Hook;

这两条原则出现的原因呢,我们后面说到原理再解释,说完了hook 使用原则,然后我们来具体说说这些神通广大的hook。

useState

useState,是干嘛的呢,存状态,改状态的,useState 解决了函数组件没有 state 的问题,让无状态组件有了自己的状态,我们知道react 用状态来控制着页面视图的更新。

useState()这个函数接受状态的初始值,作为参数;该函数返回一个数组,数组的第一个成员是一个变量,指向状态的当前值,第二个成员是一个函数,用来更状态,约定是set前缀加上状态的变量名。

我们写一个计数器组件,来展示的useState基础用法:

import React, { useState } from "react";
​
export default function  Example()  {
  // 声明一个叫 "count" 的 state 变量,然后把它的初始值设为 0, 我们可以通过调用 setCount 来更新当前的 count
  const [count, setCount] = useState(0);
​
  function handleClick()  {
    return setCount(count+1);
  }
​
  return  <button  onClick={handleClick}>{count}</button>;
}
复制代码

我们看到基础用法很简单,一看就会,那我们进阶一下。

批量更新

在此之前,我们先回忆一下react类组件对于状态的处理机制有两个关键点,批量更新,异步(模拟的异步)处理;

批量更新: 调用this.setState后状态并没有立即更新,而是先缓存起来了,等事件函数处理完后,再进行批量更新,一次更新并重新渲染。因此,我们更新状态后,如果立即去拿最新的状态是拿不到的。但并不是所有情况下,都会批量更新,我们可以这么理解,只要在react控制的区域里就会批量更新,比如: 事件处理函数,生命周期函数,只要不归react管就是非批量,比如定时器,promise等,可以立即拿到最新状态

这种优化性能的机制在函数组件里依旧保留着,那就有了两个问题,先看思考第一个,如果我们的状态依赖于前一个状态(就是我们要拿到最新状态),该怎么处理呢?先对批量更新做个实验,熟悉一下:

...
const [count, setCount] = useState(0);
​
function handleClick()  {
    setCount(count+1);
    console.log(count); // 0
    setCount('聪明蛋');
    console.log(count); // 0
    setTimeout(()=>{
      console.log(count); // 0
      setCount(count+1); 
      console.log(count); // 0
    }, 1000)
    console.log(count, 1); // 0,1
  }
  
  return  <button  onClick={handleClick}>{count}</button>
 ...
​
复制代码

看看注释的打印数据,是不是和预期的有些差异,打印结果是0,0, 0 1,0, 0;前两个打印和预期是一致的,按钮展示结果从0变成了'聪明蛋'(1s中后变成1),这就是批量更新嘛,对于同一个状态值后面的覆盖前面的么,很完美? 但是从定时器里面,就开始风格诡异了,为什么第一个打印的是0啊,不应该是'聪明蛋'么?为什么后面都是0啊,这世界怎么了?

好吧,没想到这么快就遇到hooks的一个陷阱,这个就叫闭包陷阱。不过稍微等一下,一个一个来,等我们先把上面的拿到最新状态的问题搞定,再来填这个坑。

大脑微微转动一下,什么时候我们需要拿最新的状态呢,有这个场景么?

假如我设置了状态后,需要用这个设置状态后面的状态,做些什么事,那么能设置状态就说明我们能拿到设置状态的变量,我们直接用这个变量去做不就好了,这是什么脑残问题?刷刷如下:

function handleClick()  {
    ...
    const a = xxx;
    setCount(a);
    // 想用最新的count 做些啥,直接用a 不就好了
    
  }
复制代码

嗯,上面这个想法其实是走进误区了(但不一定没用哦,没用的我不会写,这里主要是提醒一部分小友,很多场景不需要用到最新状态去做,不要执着于这个),首先你要用的那个变量不一定在一个函数内,不一定好拿,真实场景可能是这样的,比如一个相对复杂的输入组件,我要把最新的输入值和之前存的状态值合并起来得到新的状态值,比如我输入了1,我把原来的状态的某个字段改为1;

const [value, setValue] = useState({a: 1, b:2, c:3});
​
原来的状态: {
  a: 1,
  b: 2,
  c: 3
}
​
我要的状态: {
a: 1,
b: 2,
c: 1,   // 我就是想改下c
}
复制代码

你如果直接setValue({c: 1}),那之前的值就丢了。我们可以这样改:

setValue((state)=>({...state, c: 1}));
复制代码

官方说法: 如果新的 state 需要通过使用先前的 state 计算得出,那么可以将函数传递给 setState。该函数将接收先前的 state,并返回一个更新后的值;

这样写,很方便,不是么?可能有人有不同意见,觉得这种情况,我本来就可以拿到最新的值,不需要用函数拿,直接用不就好了,我完全可以先改了原来的状态 value.c = 1, 然后在setValue,不就行了,于是有一下代码:

...
value.c = 1;
setValue(value);
复制代码

​ 很好,天才想法!结果发现不生效,为啥呢,后面咱讲到原理再聊。先说下上面遇到的闭包陷阱。

闭包陷阱

先copy一下咱上面实验批量更新的代码和思路,然后再继续:

import React, { useState } from "react";
​
export default function  Example()  {
  // 声明一个叫 "count" 的 state 变量,然后把它的初始值设为 0, 我们可以通过调用 setCount 来更新当前的 count
  const [count, setCount] = useState(0);
​
  function handleClick()  {
    setCount(count+1);
    console.log(count); // 0
    setCount('聪明蛋');
    console.log(count); // 0
    setTimeout(()=>{
      console.log(count); // 0
      setCount(count+1); 
      console.log(count); // 0
      setCount((state=>{
        console.log(state); // 1
        setCount(state);
      }))
    }, 1000)
  }
​
  return  <button  onClick={handleClick}>{count?.a}{count?.b}{count?.c}</button>;
}

复制代码

我们点击一次,handleClick里,是不是和预期的有些差异,头两个打印和预期是一致的,按钮展示结果从0变成了'聪明蛋'(1s中后变成1),这就是批量更新嘛,对于同一个状态值后面的覆盖前面的么,很完美? 但是从定时器里面,就开始风格诡异了,为什么第一个打印的是0啊,不应该是'聪明蛋'么?为什么后面都是0啊,这世界怎么了?

好了,上面是复制的内容,咱们继续,先说说闭包,通俗一点说就是:一个函数返回一个不销毁的执行上下文(内部有变量被外界引用)。

那么我们在分析一下上面那段代码,当我们点击时,handleClick更新了状态,执行到setTimeout,发现是异步,于是把异步代码放进异步队列里存起来,注意,这时handleClick 里有定时器,所以这个handleClick执行到末尾时,这个作用域并不会被销毁,这就使得它外层的Example函数组件执行上下文不会被销毁,但是状态更新了,react要去更新组件Example,Example 函数再次执行,视图渲染,按钮展示聪明蛋。然后时间到了,定时器开始执行,顺着作用域链去拿count,但是它只能拿到闭包里的count 变量(0),因为作用域是在函数定义是确定下来的,在它定义时,它的上级作用域里count就是0;然后它更新了一下,把count 变成1;

好啦,上面就是闭包陷进啦,简单说就是,咱在某个没有销毁的执行上下文里用了状态,造成里面的状态只能取到闭包里的值,而不是更新后的值。

那,知道了这个陷阱,那我们要怎么破解呢,很显然上面代码其实已经给了答案(没注意的可以回头看看注释的打印),给setSate 传函数就可以解。

那我们在想一下,既然是因为闭包影响,那我把这个受影响的值存到闭包的外面(上层,比如全局),不就可以了么,所以还有第二种解法,使用useRef:

import React, { useState,useRef } from "react";
​
export default function  Example()  {
  // 声明一个叫 "count" 的 state 变量,然后把它的初始值设为 0, 我们可以通过调用 setCount 来更新当前的 count
  const [count, setCount] = useState(0);
  const R = useRef();
  R.current = count;
​
  function handleClick()  {
    setCount(count+1);
    console.log(count); // 0
    setCount('聪明蛋');
    console.log(count); // 0
    setTimeout(()=>{
      console.log(R.current); // 聪明蛋
      console.log(count); // 0
      setCount(count+1); 
      console.log(R.current, 'R'); // 1, 注意这里是里立即拿到,最新的状态值哦,说明批量更新机制是完全生效的
      console.log(count); // 0
      setCount((state=>{
        console.log(state); // 1
        console.log(R.current); // 1
        setCount(state);
      }))
    }, 1000)
    console.log(count, 1); // 0,1
  }
​
  return  <button  onClick={handleClick}>{count}</button>;
}
​
复制代码

为什么这种写法可以呢,我们稍后讲到useRef 再详细解释。我们先把useState 再进阶一下。

总结一句哈,遇到怪事就想想定时器,想想闭包,在hook中用定时器,得注意一点哦。

useState原理

写了半天,useState 还没写完,我真是醉了,感叹一句写文不易,且读且珍惜;也不着急,无非是多花我几个小时,我花费的只是时间,你们得到的可是财富啊。

我们已经知道了useSate的用法,那么闭上眼睛,沉吟30秒,让我们想一想,如果让你写个useState 你怎么写呢?

根据常规用法,那我们能很快想到,首先有个函数,接收一个初始值,返回一个数组,数组第一个值时一个状态,第二个值是个函数改变这个状态,我们可以很快写出如下代码:

const useState = (init) => {
​
  let state = init;
​
  const setState = (newState) => { // 一个改状态的方法
​
    state = newState;
​
  }
​
  return [ // 先写返回
​
    state,
​
    setState,
​
  ]
​
}
复制代码

很完美,如果别人去用我们这个这个useState,会怎样?

至少有这么两个问题:

问题1: 我们的状态会被重复初始化

第一次渲染是ok的,但是第二次更新会出问题,因为我们把state这个变量保存在里useState里,函数更新重新执行useState,我们的状态就又变成了初始值,所以我们要把state这个变量提出来,至少不能被组件函数执行影响到的地方。

问题2:一个函数组件里可能会有多个useState,我们如何保证他们执行的顺序,如何分辨他们谁是谁呢?

所以,我们不仅要把state变量提出来,还需要一个地方,把每个useState的返回值存起来,而且要记住他们的顺序。

于是,我们把上面的函数改进一下:

const hookStates = [];
let hookIndex = 0;
​
const useState = (init) => {
  hookIndex++;
  hookStates[hookIndex] = hookStates[hookIndex] || init;
  const setState = (newState) => {
      hookStates[hookIndex] = newState;
      // 然后开始进入更新应用逻辑
      ...
    }
  return [hookStates[hookIndex], setState];
}
复制代码

这样是不是就解决了上面的问题了,用hookIndex记录hook的顺序,在用个数组把hooks的返回值存起来就好了呗,把有小友可能会怀疑,这个useState它正经吗,能用吗,放心拿去用,没得问题。

不过嘛,毕竟是咱自己模拟的,只能模拟下原理,和源代码还是有那么一点点差异的,源码里呢,hooks状态是存在函数组件对应的fiber节点上,也不是用数组存储,是用链表来存储hook的相关信息,顺序呢,就是每次找当前节点的next就好了。useState的参数可以是一个值或者一个函数,是函数时会把它执行,然后取返回值。不过道理呢就是这个道理,也差不多。react hooks 大部分都类似这种机制。

这个过程中解释了一个问题,就是hooks 规则,hooks 为什么要通常放在顶部,hooks 不能写在 if 条件语句中,因为在更新过程中,如果通过 if 条件语句,增加或者删除 hooks,在复用 hooks 过程中,会产生复用 hooks 状态和当前 hooks 不一致的问题。

useEffect

useEffect() 用来引入具有副作用的操作;

解释一下副作用: 我们想在 React 更新 DOM 之后运行一些额外的代码,网络请求,操作dom,订阅外部数据源,我们基本上都希望在 React 更新 DOM 之后才执行我们的操作;

useEffect()的用法如下:

useEffect(()  =>  {
  // Async Action
  return clearFn();
}, [dependencies])

复制代码

上面用法中,useEffect() 接受两个参数。第一个参数是一个函数,异步操作代码放里面,如果这个函数返回了一个函数,那么返回的这个函数会被当做清除副作用的函数。第二个参数是一个数组,用于给出Effect的依赖项,只要这个数组发生变化,useEffect() 就会执行。第二个参数可以省略,这样每次组件函数执行时,都会执行useEffect()。

使用useEffect要注意这么几点,官方是这么说的(括号里是我的补充):

传递给 useEffect 的函数在每次渲染中都会有所不同(是一个新创建的函数), 每次我们重新渲染,都会生成新的 effect,替换掉之前的, 这也是我们可以在 effect 中获取最新的状态值的原因;

React 会在执行当前 effect 之前对上一个 effect 进行清除(如果useEffect里的副作用函数返回了清除函数,就会在这时执行), 先清除副作用,后执行, 清除函数会在组件卸载前也会执行;

传给 useEffect 的函数会在浏览器完成布局与绘制,画面渲染之后,在一个延迟事件中被调用。这使得它适用于许多常见的副作用场景,比如设置订阅和事件处理等情况,因为绝大多数操作不应阻塞浏览器对屏幕的更新。

如果要与类组件对比呢,我们可以这么理解理解: useEffect相当于,componentDidMount,componentDidUpdate和componentWillUnmount的集合,它以一抵三。hooks可以反复多次使用,相互独立。所以我们合理的做法是,给每一个副作用一个单独的useEffect钩子。

用法和注意事项就这么多,那么,我们再写个简单demo吧,我们为上面咱写的计数器增加了一个小功能:将 document 的 title 设置为包含了点击次数的消息(没有写依赖数组,所以每次渲染副作用都会执行):

import React, { useState, useEffect } from 'react';
​
function Example() {
  const [count, setCount] = useState(0);
​
  useEffect(() => {
    document.title = `You clicked ${count} times`;
  });
​
  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>
        点我
      </button>
    </div>
  );
}
复制代码

好了,useEffect讲完了,关键点都在上面,就这么多东西,反复阅读就ok了,不过看起来内容有点少(很多文章讲闭包陷阱都用写定时器的栗子来讲,会用到useEffect,不过这个内容我上面讲过,就不重复了,怎么跳出陷阱的原理已经讲了,你学会了么?有兴趣自己实现一个每秒加一的计数器效果,考验一下自己吧),这个hook还是用的挺多,那再补充一点内容吧,说下useEffect的依赖。

对于依赖数组内部元素,使用的是浅比较(===, 引用相等),如果数组内部依赖的引用变了,会当成依赖变了,所以如果在渲染过程中传递函数,对象,不用useCallback , useMemo 包裹的话,会造成依赖每次都变的效果; 所以建议useEffect 内使用函数,函数 写在useEffect 内,或者组件函数外, 实在不行用useCallback 包裹,作为useEffect依赖;

如果依赖是一个空数组,就是让副作用函数只用挂载后,和卸载前执行。

useEffect 原理

说下useEffect原理,和useState 其实是类似的,咱模拟一下吧:

const hookStates = [];// 保存数据状态的数组,每个组件只有一个
let hookIndex = 0; // 索引// useLayoutEffect(这个hook咱们后面说) 和 useEffect 实现一样,只不过useLayoutEffect是同步的(在同步代码的最后执行), useEffect 用宏任务,还多了个销毁步骤
function useEffect(callback, deps){
  if(hookStates[hookStates]){ // 说明不是第一次
    let [oldDestroy,lastDeps] = hookStates[hookIndex];
    const same = deps.every((item, index) => item === lastDeps[index]); // 浅比较
    if(same){
      hookIndex++; // 如果依赖相同就不执行副作用
    }else{
      oldDestroy(); // 执行副作用前,先执行清除函数
      let destroy;
      // 添加一个宏任务,在本次渲染之后执行
      setTimeout(()=>{
        destroy = callback();
        hookStates[hookIndex++] = [destroy,deps]; // 存一下清除函数,和依赖,下次更新用
      }, 0);
    }
  }else{ // 初始化
    let destroy;
    // 添加一个宏任务,在本次渲染之后执行
    setTimeout(()=>{
      destroy = callback();
      hookStates[hookIndex++] = [destroy,deps];
    }, 0);
  }
}
​
复制代码

那有小友可能就要问了,这个高仿useEffect和源码的差别又在那里呢,特别是在执行的时机那里,是用的定时器么?嗯,原理差不多啦。react源码不是很好看,但是原理说清了,再看起来就会简单很多,小友有时间可以找源码研究一哈。

这个高仿useEffect,除了上面已经说过的存储位置和存储数据结构差异外,还有执行时机的区别,源码里不是直接用setTimeout这个api实现的,在React 17 中,这个特性是借助 MessageChannel实现的,MessageChannel就是一个微任务, 那么为什么不用 setTimeout(0)呢,原因是递归执行 setTimeout(fn, 0) 时,最后间隔时间会变成 4 毫秒左右,而不是最初的 1 毫秒。我们知道浏览器一帧大概是16ms时间,4ms对于浏览器的一帧16ms时间过于浪费。

useRef

useRef 很简单啊!

官方这么说的:useRef() 和自己建一个 {current: ...} 对象的唯一区别是,useRef 会在每次渲染时返回同一个 ref 对象, 类似于在 class 中使用实例(this)字段的方式(可以把其返回值看做一个全局变量,多次渲染指向始终不变);

所以,你明白了上面useRef 为什么能解闭包问题了吧,因为每次都返回了同一个对象(引用地址没有变)。

咱常常这么用:

const ref = React.useRef();
​
...

<div  ref={ref} >
​
复制代码

用ref.current 取dom; 如果给React.useRef()传个参数,那么ref.current就指向这个参数

useMemo 和 useCallback

这两兄弟一起讲吧,他们很像, 都接收两个参数,第一个参数是回调函数,第二个参数是依赖数组。

useCallback(fn, deps) 相当于 useMemo(() => fn, deps)。 useMemo用来缓存对象(函数返回的对象, 依赖没有变,对象就不需要重新计算), 返回缓存对象。

useCallback用来缓存函数,返回缓存函数。

官方这么说的:如果你在渲染期间执行了高开销的计算,则可以使用 useMemo(或者 useCallback) 来进行优化。

注意哦,这两个只是优化方法,不要滥用哦。有的小友喜欢什么都包一下,个人觉得不合适,不合适,如果没有察觉不到性能问题,何必多此一举呢,按需取用比较好一点。当然如果你习惯包一下,那就包一下嘛,无可厚非,非要说的话,在内存消耗与渲染开销之间做一个平衡就好,我觉得这是一个见仁见智的问题。

一般这么用:

const fn = useCallback(()=>{...}, deps);
复制代码

useMemo 原理

useMemo 和 useCallback 很像,我们仿一个就行了。

const hookStates = [];// 保存数据状态的数组,每个组件只有一个
let hookIndex = 0; // 索引
​
function useMemo(callback, deps) {
  if (hookStates[hookIndex]) {
    // 说明不是第一次
    let [laseMemo, lastDeps] = hookStates[hookIndex];
    // 判断一下依赖是否变化
    let same = deps.every((item, index) => item === lastDeps[index]);
    if (same) {
      hookIndex++;
      return laseMemo;
    } else {
      let newMemo = callback(); // 与callback 不同的地方
      hookStates[hookIndex++] = [newMemo, deps];
      return newMemo;
    }
  } else {
    // 初始化
    let newMemo = callback(); // 与useCallback 不同的地方
    hookStates[hookIndex++] = [newMemo, deps];
    return newMemo;
  }
}
复制代码

useCallback 同理,只返回时直接返回索引值就好。

useLayoutEffect

这个,用的比较少。

官方是这么说的:

一个对用户可见的 DOM 变更就必须在浏览器执行下一次绘制前被同步执行,这样用户才不会感觉到视觉上的不一致。React 为此提供了一个额外的 useLayoutEffect Hook 来处理这类 effect。它和 useEffect 的结构相同,区别只是调用时机不同

useLayoutEffect 与 componentDidMount、componentDidUpdate 的调用阶段是一样的, 它会在所有的 DOM 变更之后同步调用 effect, 可以使用它来读取 DOM 布局并同步触发重渲染, 推荐你一开始先用 useEffect,只有当它出问题的时候再尝试使用 useLayoutEffect。

有一点点绕,说人话就是: useEffect在浏览器渲染结束后执行,useLayoutEffect 则是在dom更新后,浏览器绘制前执行。

useEffect不会阻塞浏览器渲染,是用宏任务实现的,而useLayoutEffect会阻塞浏览器渲染,在渲染前执行,是同步的,如果希望页面刷新尽可能快,可以用这个useLayoutEffect,比如拖拽。

useLayoutEffect 和 useEffect 原理差不多(就不写了),只不过useEffect 用宏任务,useLayoutEffect呢,react内部是通过同步代码去控制他的执行时机(我们高仿的话也可以用微任务,能得到同样的渲染效果,因为在一个事件环里,同步代码和微任务都是在浏览器画页面前执行) ,useEffect还多了个销毁步骤。

这里说到微任务,宏任务,就简单说一下浏览器的事件环吧:

主栈代码执行,遇到宏任务(定时器什么的),放进宏任务队列,遇见微任务(promise 什么的),放进微任务队列,主栈任务清空后,会清空微任务队列里的所有任务,然后js线程挂起,浏览器开始渲染页面(GUI 渲染线程和 JS 引擎线程是相互排斥的),之后再会取出一个宏任务在主栈里执行。如此循环。

useImperativeHandle 和 forwardRef

这个,用的也挺少。

官方说法: useImperativeHandle 可以让你在使用 ref 时自定义暴露给父组件的实例值, useImperativeHandle 应当与 forwardRef 一起使用。forwardRef会创建一个React组件,这个组件能够将其接受的ref属性转发到其组件树下的另一个组件中。

Ref 转发是一个可选特性,其允许某些组件接收 ref,并将其向下传递(换句话说,“转发”它)给子组件

解释补充一下吧:

类组件是有实例的,所以给类组件加ref属性,ref.current 就等于类实例,但是如果想给直接给函数组件增加ref属性就不行。这就需要forwardRef。forwardRef可以将ref从父组件转发到子组件的dom元素上,这样父组件就可以操作子组件元素,但父组件可以随意子组件元素,容易出问题。所以要用useImperativeHandle,限制父组件的能力。

咱一般这么用:

引入:

import React, {useRef, useImperativeHandle, forwardRef} from 'react';
复制代码

父组件:

export default function App(){
  const  inputRef = useRef();
  return  <>
    <span onClick={()=>{inputRef.current.focus();}}>点我获得焦点</span>
    <WrapChild ref = {inputRef}/> // 传给子组件
  </>
}
复制代码

子组件:


function Child(props, ref){ // 注意ref 是个形参哦,子组件第二个参数接收了ref
  const inputRef = useRef();
  // 在组件组件中用useImperativeHandle来限制父组件:
  useImperativeHandle(ref,()=>( // 这里做了ref 的关联
    {
      focus(){
        inputRef.current.focus();
      }
    }
  ));
  return <input ref = {inputRef}/>
}
const wrapChild = forwardRef(Child)
export default wrapChild;
​
复制代码

这样父组件里的inputRef就只能调用focus方法。 在上述的示例中,React 会将 元素的 ref 作为第二个参数传递给 React.forwardRef 函数中的渲染函数。该渲染函数会将 ref 传递给 元素,因此,当 React 附加了 ref 属性之后,ref.current 将直接指向 DOM 元素实例。

useReducer

官方说: 在某些场景下, useReducer 会比 useState 更适用,例如 state 逻辑较复杂且包含多个子值(可以理解为复杂状态的放在一个地方统一维护)

可以这么理解: useState 是 useReducer 的简化版,语法糖。

主要用来做复杂状态的统一管理,比我们使用useState时,更希望这个状态纯粹简单,一般我们喜欢一个组件里,写很多useState。但有时项目里有一些复杂的状态,比如用户信息什么的,我们希望放在一块管理,可以用这个useReducer。总之维护复杂的状态可以考虑useReducer。

我们一般这么用:

const [state, dispatch] = useReducer(reducer, initialState);
复制代码

上面是useReducer()的基本用法,它接受reducer函数和状态的初始值作为参数,返回一个数组,数组的第一个成员是状态的当前值,第二个成员是发送的action的dispatch函数。

举个栗子,下面是一个计数器的例子,用于计算状态的reducer函数如下:

const myReducer = (state, action) => {
  switch(action.type)  {
    case 'countUp':
      return  {
        ...state,
        count: state.count + 1
      }
    default:
      return  state;
  }
}
复制代码

组件代码如下:

function App() {
  const [state, dispatch] = useReducer(myReducer, { count:   0 });
  return  (
    <div className="App">
      <button onClick={() => dispatch({ type: 'countUp' })}>
        +1
      </button>
      <p>Count: {state.count}</p>
    </div>
  );
}
复制代码

由于 Hooks 可以提供共享状态和 Reducer 函数,所以它在某些方面可以取代 Redux。redux 是react 世界状态管理的扛把子,说到redux,就说到状态管理 ,那他是怎么取代Redux,来做简单项目的状态管理呢?我们先说说useContext这个hook,然后再回答这个问题。

useContext

官方说法:

const value = useContext(MyContext);
复制代码

useContext(MyContext), 接收一个 context 对象(React.createContext 的返回值)并返回该 context 的当前值。当前的 context 值由上层组件中距离当前组件最近的 <MyContext.Provider> 的 value prop 决定。

当组件上层最近的 <MyContext.Provider> 更新时,该 Hook 所在组件会触发重渲染, React.memo无法阻止这种渲染。

那咱们现在来用一下,先来最简单的:

const AppContext = React.createContext(); // 定义context;
​
<AppContext.Provider value={{
  username: 'superawesome'
}}>
  <div className="App">
    <Navbar/>
    <Messages/>
  </div>
</AppContext.Provider>
​
复制代码

子级组件使用

const Navbar = () => {
    const {username} = useContext(AppContext);  // 获取context
    return (
    <div className="navbar">
      <p>AwesomeSite</p>
      <p>{username}</p>
    </div>
  );
}
复制代码

当然,应该没人会这么用,太傻了,不符合实际业务场景,我们实际使用的使用时候,一般结合useReducer来用,可以用来做简单项目的状态管理。

做状态管理呢,我们至少需要三个东西,一个是我们的状态集(也就是数据),一个是用来改变状态的东西(更新视图的东西),还需要一个管理他们的东西。

举个栗子,就写个计数器吧,我们先定义一下数据管理文件,定义好context,和reducer:

import {createContext} from 'react';
​
export const CommonContext = createContext({}); 
​
export const CommonReducer = (state, action) => {
  switch(action.type){
    case 'increment':
      return { count: state.count+ 1};
    case 'decrease':
      return {count: state.count-1};
    default: 
      throw new Error();
  }
}
复制代码

然后定义我们的父级组件,用上面定义的context传值,传出去dispatch函数(改变状态的东西),和state 数据(状态集):

import { CommonContext, CommonReducer } from './store';
import Child from './child';
​
export default function Counter() {
  const [state, dispatch] = useReducer(CommonReducer, {count: 3});
  return (
    <CommonContext.Provider value={{ dispatch, state }}>
        <Child />
    </CommonContext.Provider>
  );
}
复制代码

我们父级组件在和最后一级组件之间,可能还有很多级组件,比如上面引入的./child文件是下面这样的:

import GrandSon1 from './grandson';
export default function C () {
  return (
    <div>
      <GrandSon/>
    </div>
  );
}
复制代码

我们在最后一级组件里取值, 注意要从数据文件里引入同一个context:

import { CommonContext } from './store'
export default function Counter() {
  const { dispatch, state } = useContext(CommonContext);
  return (
    <div>
      <button onClick={() => dispatch({ type: 'decrease' })}>grandson-{state.count}</button>
    </div>
  );
}
复制代码

这样一个简单的计数器就写好了。我们就可以用这个来做状态管理,做一些跨多级(平行)组件传递信息的事情。

但是,这里可能有一个问题,就是咱每次调用dispatch更新状态的时候,组件会从CommonContext.Provider开始都重新渲染一遍(如果把useReducer理解成一个加强版useState, 我们其实就是更新了根组件的状态,子组件必然会刷新)。

如果我们的项目简单,不需要频繁的这么传递信息,当然可以用这种方式,多一些渲染消耗我们也能接受,我们可以随便在哪里dispatch就好。

但是,如果项目复杂了,我们还这么搞,每次都从根组件开始更新渲染,无疑很让人头大,当然我们有各种方法去优化这种更新,比如用useMemo包一下组件,但是写业务的时候,总是背着这种要优化的包袱,让人束手束脚,不是一个好现象,我希望写大部分业务的时候,我可以闭着眼睛写也不会出错。所以,我们需要专业的状态管理工具。

想到react 专业的状态管理,我们首先会想到redux,但这个工具有点稍重,然后会想到mobx,嗯...篇幅有限,就不在这里继续展开了。

自定义hook

官方说法: 自定义 Hook 是一个函数,其名称以 “use” 开头,函数内部可以调用其他的 Hook。

简单吧。

只要一个函数以use开头,并且里面调用了别的hook,那它就是一个自定义hook。

好了,既然你已经读完了全文,嗯,你现在已经是一个react hook小高手了。

分类:
前端
标签:
收藏成功!
已添加到「」, 点击更改