• 从React源码角度看useCallback,useMemo,useContext


    热身准备

    useCallbackuseMemo是一样的东西,只是入参有所不同。

    useCallback缓存的是回调函数,如果依赖项没有更新,就会使用缓存的回调函数;

    useMemo缓存的是回调函数的return,如果依赖项没有更新,就会使用缓存的return

    官网有这样一段描述useCallback(fn, deps) 相当于 useMemo(() => fn, deps)

    所以这里,只以useCallback为例进行分析。

    初始化 mount

    mountCallback

    如果各位看官是系列文章第一篇开始看的,看到这里估计就无压力,mountCallback就这几行代码,笔者没有做精简。

    function mountCallback(callback, deps) {
      // 初始化hook结构
      var hook = mountWorkInProgressHook();
      // 使用者传进来的依赖数组
      var nextDeps = deps === undefined ? null : deps;
      // 以数组的形式将回调和依赖数组存储到对应fiber.memoizedState.hook.moeoizedState
      hook.memoizedState = [callback, nextDeps];
      return callback;
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9

    更新 update

    function updateCallback(callback, deps) {
      var hook = updateWorkInProgressHook();
      var nextDeps = deps === undefined ? null : deps;
      var prevState = hook.memoizedState;
    
      if (prevState !== null) {
        if (nextDeps !== null) {
          var prevDeps = prevState[1];
    
          if (areHookInputsEqual(nextDeps, prevDeps)) {
            return prevState[0];
          }
        }
      }
    
      hook.memoizedState = [callback, nextDeps];
      return callback;
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18

    updateCallback就这几行代码,没有删减,代码意图也很简单,如果依赖数组deps没有变化,或者deps=[]的情况下,会返回之前缓存的回调函数,否则就更新对应fiber.memoizedState.hook.memoizedState并返回新的回调函数。

    使用场景

    就笔者的所见所闻,存在两种极端情况,一种开发者在开发时,不管什么函数,什么数据都喜欢使用useCallbackuseMemo进行一层包裹。还有一种开发者不管什么情况都不会考虑使用useCallbackuseMemo

    不用说,这两种做法都是有问题的。第一种做法,还不知道是之所以会出现这样的问题,根本原因还是很多开发者并不明白这两个hook的原理和使用场景。

    首先,我们要明确函数组件在每一次更新时,都会执行函数组件,函数组件内部的所有方法,所有值都会重新声明,重新计算。这两个hook的出现就是为了优化这种情况,避免不必要的浪费。而这两个hook的做法就是通过将函数或者值存储在对应的fiber.memoizedState.hook.memoizedState上,在下次更新时,根据依赖项是否变化来决定是否要用缓存值,还是新的传进来的值。

    这时候可能有人疑惑既然都会更新,那我全部包裹起来有什么不好?笔者认为都进行包裹主要的问题是,如果一个函数足够简单,从新声明可能性能消耗会比包裹后存储在hook.memoizedState的消耗更小。

    这里,笔者根据自己看源码的心得,列举下这两个hook的使用场景:

    1. 如果子组件比较复杂,可以考虑使用useCallback进行包裹;
    2. 如果函数组件中某个值需要大量的计算才能得出,可以考虑使用useMemo进行包裹;
    3. 如果某个函数是子组件的props,可以考虑使用useCallback进行包裹(配合React.memo使用);
    4. 自定义hooks中复杂逻辑可以考虑使用useCallbackuseMemo进行包裹;

    相关参考视频讲解:进入学习

    总结

    这两个hook原理还是很简单的,因为是系列文章,很多内容和前面文章都重复了,所以导致这篇都没啥能写的了。总结下原理:

    这两个hook的做法就是通过将函数或者值存储在对应的fiber.memoizedState.hook.memoizedState上,在下次更新时,根据依赖项是否变化来决定是要用缓存值,还是新的传进来的值。

    虽然useCallbackuseMemo是为了优化性能出现的,但是各位看官也不要盲目使用,毕竟这两个hook本身也会带来开销。

    看完这篇文章, 我们可以弄明白下面这几个问题:

    1. useCallbackuseMemo的区别?
    2. useCallbackuseMemo的使用场景有哪些?
    3. useCallbackuseMemo是做什么的?
    4. useCallbackuseMemo是怎么实现优化性能的?

    热身准备

    useContext可以帮助我们跨越组件层级直接传递变量,避免了在每一个层级手动的传递 props 属性,实现共享,要配合createContext使用。

    createContext

    createContext主要功能是创建一个context,提供ProviderConsumerProvider主要将context内容暴露出来,Consumer可以拿到对应contextProvider暴露的内容使用。

    示例代码:

    export const Context = createContext(null)
    
    <Context.Provider value='initialValue'>
      <Context.Consumer>
        {(v) => {      return <h2>{v}</h2>
        }}  </Context.Consumer>
    </Context.Provider>
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7

    Provider

    在渲染时,beginWork阶段,会执行

    pushProvider(workInProgress, newValue);
    
    • 1

    它会将Providerprop上的value字段存到context._currentValue中。

    Consumer

    在渲染时,beginWork阶段,会执行

    prepareToReadContext(workInProgress, renderLanes);
    var newValue = readContext(context, newProps.unstable_observedBits);
    
    • 1
    • 2

    通过上面代码可以拿到Providerprop上的value

    值得注意的是, Consumer标签下包裹的必须是一个函数,如果不是函数会报错。 Consumer会将拿到的value作为函数的参数传入函数中去使用。如同上面示例代码中获取到的v

    useContext

    useContext需要将createContext创建的Context作为参数进行调用。

    值得一提的是,前面讲的hook在初始化和更新时会有两套不同函数执行。但是在useContext只有一个,也就是useContext在初始化和更新时执行的是一套代码。

    初始化 mount & 更新 update

    useContextmount时主要会调用readContext函数:

    function readContext(context, observedBits) {
    
      var contextItem = {
        context: context,  // 传入的context
        observedBits: resolvedObservedBits,  // 观察范围(默认全部update)
        next: null
      };
    
      lastContextDependency = contextItem;
      currentlyRenderingFiber.dependencies = {
        lanes: NoLanes,
        firstContext: contextItem,
        responders: null
      };
      } else {
        // Append a new context item.    lastContextDependency = lastContextDependency.next = contextItem;
      }
    
      return  context._currentValue ;
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20

    精简了下代码,可以看到,readContext会创建一个contextItem并以链表的结构记录在对应fiber.dependencies上,最后将Providerprop上的value返回。

    总结

    useContext的原理类似于观察者模式。Provider是被观察者, ConsumeruseContext是观察者。当Provider上的值发生变化, 观察者是可以观察到的,从而同步信息给到组件。

    主要使用场景就是多层级组件值的传递,如果值较多可以考虑配合useReducer使用。

    看完这篇文章, 我们可以弄明白下面这几个问题:

    1. useContext的原理是什么?
  • 相关阅读:
    ansible
    2022年最新Python大数据之Python基础【七】参数与管理系统
    Mybatis分页框架-PageHelper
    罗丹明标记的葡聚糖 70k,RB-Dextran,MW:70K
    CAD进阶练习(四)
    Redis入门到通关之数据结构解析-ZipList
    Mysql应用日志时间与系统时间相差八小时
    孔松(信通院)-数字化时代云安全能力建设及趋势
    12_AJAX
    【AI大模型】Transformers大模型库(十一):Trainer训练类
  • 原文地址:https://blog.csdn.net/It_kc/article/details/127763675