学习
实践
活动
工具
TVP
写文章
专栏首页QQ音乐前端团队专栏React Hooks 源码解析(4):useEffect

React Hooks 源码解析(4):useEffect

  • React 源码版本: v16.11.0
  • 源码注释笔记:airingursb/react

1. useEffect 简介

1.1 为什么要有 useEffect

我们在前文中说到 React Hooks 使得 Functional Component 拥有 Class Component 的特性,其主要动机包括:

  1. 在组件之间复用状态逻辑很难
  2. 复杂组件变得难以理解
  3. 难以理解的 class

对于第二点,首先,针对 Class Component 来说,我们写 React 应用时经常要在组件的各种生命周期中编写代码,如在 componentDidMountcomponentDidUpdate 中发送 HTTP 请求、事件绑定、甚至做一些额外的逻辑,使得业务逻辑扎堆在组件的生命周期函数中。在这个时候,我们的编程思路是“在组件装载完毕时我们需要做什么”、“在组件更新时我们需要做什么”,这使得 React 开发成为了面向生命周期编程,而我们在生命周期中写的那些逻辑,则成了组件生命周期函数的副作用

其次,面向生命周期编程会导致业务逻辑散乱在各生命周期函数里。比如,我们在 componentDidMount 进行的事件绑定又需要在 componentDidUnmount 解绑,那事件管理的逻辑就不统一,代码零散 review 起来会比较麻烦:

import React from 'react'class A extends React.Componment {  componmentDidMount() {    document.getElementById('js_button')      .addEventListener('click', this.log)  }  componentDidUnmount() {    document.getElementById('js_button')      .removeEventListener('click', this.log)  }
  log = () => {    console.log('log')  }
  render() {    return (      <div id="js_button">button</div>    )  }}

useEffect 的出现,则让开发者的关注点从生命周期重新抽离出来聚焦在业务逻辑之上,其实 effect 的全称就是 side effect,即副作用,useEffect 就是用来处理原本生命周期函数里的副作用逻辑。

接下来,我们看看 useEffect 的用法。

1.2 useEffect 的用法

上面那段代码用 useEffect 改写之后如下:

import React, { useEffect } from 'react'function A() {
  log() {    console.log('log')  }
  useEffect(() => {    document      .getElementById('js_button')      .addEventListener('click', log)    return () => {      document        .getElementById('js_button')        .removeEventListener('click', log)    }  })
  return (<div id="js_button">button</div>)} 

useEffect 接受两个参数,第一个参数是一个 function,其实现 bind 操作并将 unbind 作为一个 thunk 函数被返回。第二个参数是一个可选的 dependencies 数组,如果dependencies 不存在,那么 function 每次 render 都会执行;如果 dependencies 存在,只有当它发生了变化,function 才会执行。由此我们也可以推知,如果 dependencies 是一个空数组,那么当且仅当首次 render 的时候才会执行 function。

useEffect(  () => {    const subscription = props.source.subscribe();    return () => {      subscription.unsubscribe();    };  },  [props.source],);

更多用法请阅读 React 官网的 useEffect API 介绍: https://reactjs.org/docs/hooks-reference.html#useeffect

2. useEffect 的原理与简单实现

根据 useEffect 的用法,我们可以自己实现一个简单的 useEffect:

let _deps;
function useEffect(callback, dependencies) {  const hasChanged = _deps    && !dependencies.every((el, i) => el === _deps[i])    || true;  // 如果 dependencies 不存在,或者 dependencies 有变化,就执行 callback  if (!dependencies || hasChanged) {    callback();    _deps = dependencies;  }}

3. useEffect 源码解析

3.1 mountEffect & updateEffect

useEffect 的入口和上一节中 useState 的一样,都在 ReactFiberHooks.js 这个文件中,并且同 useState 一样,在首次加载时 useEffect 实际执行的是 mountEffect,之后每次渲染执行的是 updateEffect,此处不再赘述。那我们需要重点看看 mountEffect 和 updateEffect 实际做了什么。

对于 mountEffect:

function mountEffect(  create: () => (() => void) | void,  deps: Array<mixed> | void | null,): void {  return mountEffectImpl(    UpdateEffect | PassiveEffect,    UnmountPassive | MountPassive,    create,    deps,  );}

对于 updateEffect:

function updateEffect(  create: () => (() => void) | void,  deps: Array<mixed> | void | null,): void {  return updateEffectImpl(    UpdateEffect | PassiveEffect,    UnmountPassive | MountPassive,    create,    deps,  );}

mountEffect 和 updateEffect 的入参是一个 function 和一个 array,对应的就是我们前文 useEffect 传的 callback 和 deps。同时,我们可以发现 mountEffect 和 updateEffect 实际调用的是 mountEffectImpl 和 updateEffectImpl,它们接受的四个参数一模一样的,后面两个参数直接透传的不用说,主要是前面的 UpdateEffect|PassiveEffectUnmountPassive|MountPassive 究竟是什么?

阅读代码可知他们是从 ReactSideEffectTagsReactHookEffectTags 中引入的。

import {  Update as UpdateEffect,  Passive as PassiveEffect,} from 'shared/ReactSideEffectTags';import {  NoEffect as NoHookEffect,  UnmountPassive,  MountPassive,} from './ReactHookEffectTags';

看一下 ReactSideEffectTags.js 与 ReactHookEffectTags.js 中的定义:

// Don't change these two values. They're used by React Dev Tools.export const NoEffect = /*              */ 0b0000000000000;export const PerformedWork = /*         */ 0b0000000000001;
// You can change the rest (and add more).export const Placement = /*             */ 0b0000000000010;export const Update = /*                */ 0b0000000000100;export const PlacementAndUpdate = /*    */ 0b0000000000110;export const Deletion = /*              */ 0b0000000001000;export const ContentReset = /*          */ 0b0000000010000;export const Callback = /*              */ 0b0000000100000;export const DidCapture = /*            */ 0b0000001000000;export const Ref = /*                   */ 0b0000010000000;export const Snapshot = /*              */ 0b0000100000000;export const Passive = /*               */ 0b0001000000000;export const Hydrating = /*             */ 0b0010000000000;export const HydratingAndUpdate = /*    */ 0b0010000000100;
export const NoEffect = /*             */ 0b00000000;export const UnmountSnapshot = /*      */ 0b00000010;export const UnmountMutation = /*      */ 0b00000100;export const MountMutation = /*        */ 0b00001000;export const UnmountLayout = /*        */ 0b00010000;export const MountLayout = /*          */ 0b00100000;export const MountPassive = /*         */ 0b01000000;export const UnmountPassive = /*       */ 0b10000000;

这么设计是为了简化类型比较与类型复合,如果项目开发的过程中有过一些复合权限系统的设计经验,那么可能第一眼就能反应过来,所以 UnmountPassive|MountPassive 就是 0b11000000。如果对应的位为非零,则表示 tag 实现了指定的行为。这个在未来会用到,我们这里先不涉及,所以就先放在这里了解即可。

3.2 mountEffectImpl & updateEffectImpl

接着我们来看看 mountEffectImplupdateEffectImpl 的具体实现。

3.2.1 mountEffectImpl

首先是 mountEffectImpl

function mountEffectImpl(fiberEffectTag, hookEffectTag, create, deps): void {  const hook = mountWorkInProgressHook(); // 创建一个新的 Hook 并返回当前 workInProgressHook  const nextDeps = deps === undefined ? null : deps;  sideEffectTag |= fiberEffectTag;  hook.memoizedState = pushEffect(hookEffectTag, create, undefined, nextDeps);}

mountWorkInProgressHook 我们在第 3 篇 4.3.3: mountWorkInProgressHook 中解析过,其就是创建一个新的 Hook 并返回当前 workInProgressHook,具体原理不再赘述。

sideEffectTag 是按位或上 fiberEffectTag 然后赋值,在 renderWithHooks 中挂载在 renderedWork.effectTag 上,并在每次渲染后重置为 0。

renderedWork.effectTag |= sideEffectTag;sideEffectTag = 0;

具体 renderedWork.effectTag 有什么用,我们后续会说到。

renderWithHooks 在 第 3 篇 4.3.1: renderWithHooks 中解析过,此处不再赘述。

hook.memoizedState 记录 pushEffect 的返回结果,这个同记录 useState 中的 newState 的原理是一致的。那么现在的重点转移到了 pushEffect 究竟做了什么。

3.3.2 updateEffectImpl

接下来我们看看 updateEffectImpl 又做了些什么工作呢?

function updateEffectImpl(fiberEffectTag, hookEffectTag, create, deps): void {  const hook = updateWorkInProgressHook(); // 获取当前正在工作中的 Hook  const nextDeps = deps === undefined ? null : deps;  let destroy = undefined;
  if (currentHook !== null) {    const prevEffect = currentHook.memoizedState;    destroy = prevEffect.destroy;    if (nextDeps !== null) {      const prevDeps = prevEffect.deps;      if (areHookInputsEqual(nextDeps, prevDeps)) {        pushEffect(NoHookEffect, create, destroy, nextDeps);        return;      }    }  }
  sideEffectTag |= fiberEffectTag;  hook.memoizedState = pushEffect(hookEffectTag, create, destroy, nextDeps);}

updateWorkInProgressHook 我们在第 3 篇 4.4.3: updateWorkInProgressHook 中解析过,其就是获取当前正在工作中的 Hook,具体原理不再赘述。

可以发现在 currentHook 为空的时候, updateEffectImpl 的逻辑与 mountEffectImpl 的逻辑是一模一样的;当 currentHook 不为空的时候, pushEffect 的第三个参数不是 undefined,而是 destroy。并且,在这个分支存在 areHookInputsEqual(nextDeps,prevDeps),即如果当前 useEffect 的 deps 和上一阶段的 useEffect 的 deps 相等( areHookInputsEqual 所做的事情就是遍历比较两个 deps 是否相等,这里就不展开解读了),那就执行 pushEffect(NoHookEffect,create,destroy,nextDeps);,大胆猜测 NoHookEffect 的意思就是不执行这次的 useEffect。如此,这段代码的逻辑就和我们之前自己实现的 useEffect 是一致的。

根据 第 3 篇 4.4.3: updateWorkInProgressHook,我们得知 currentHook 就是当前阶段正在处理的 Hook,其正常逻辑下不会为空。那我们接下来需要重点关注的应该是 pushEffect 做了什么,其第三个参数有什么含义?

3.3 pushEffect

function pushEffect(tag, create, destroy, deps) {
  // 声明一个新的 effect  const effect: Effect = {    tag,    create,     destroy,    deps,     // Circular    next: (null: any), // 函数组件中定义的下一个 effect 的引用  };  if (componentUpdateQueue === null) {    componentUpdateQueue = createFunctionComponentUpdateQueue(); // 初始化 componentUpdateQueue    componentUpdateQueue.lastEffect = effect.next = effect;  } else {    const lastEffect = componentUpdateQueue.lastEffect;    if (lastEffect === null) {      componentUpdateQueue.lastEffect = effect.next = effect;    } else {      const firstEffect = lastEffect.next;      lastEffect.next = effect;      effect.next = firstEffect;      componentUpdateQueue.lastEffect = effect;    }  }  return effect;}
type Effect = {  tag: HookEffectTag, // 一个二进制数,它将决定 effect 的行为  create: () => (() => void) | void, // 绘制后应该运行的回调  destroy: (() => void) | void, // 用于确定是否应销毁和重新创建 effect  deps: Array<mixed> | null, // 决定重绘制后是否执行的 deps  next: Effect, // 函数组件中定义的下一个 effect 的引用};

这个函数首先根据入参声明了一个新的 effect,数据结构也给出来了,它同样也是一个循环链表。tag 是

接下来根据 componentUpdateQueue 是否为空走两套逻辑,而 componentUpdateQueue 的结构其实很简单:

export type FunctionComponentUpdateQueue = {  lastEffect: Effect | null,};

可见,componentUpdateQueue 其实就是一个存储 Effect 的全局变量。

  1. componentUpdateQueue 为空:这种情况就是 mountEffect 时候的逻辑,它会创建一个空的 componentUpdateQueue,它其实只是 {lastEffect:null},之后将 componentUpdateQueue.lastEffect 指向 effect.next,其实就是存了一下 effect。
  2. componentUpdateQueue 不为空:这种情况就是 updateEffect 时候会走到的逻辑
  3. lastEffect 为空:这种情况是新的渲染阶段的第一个 useEffect,逻辑处理和 componentUpdateQueue 为空时一致。
  4. lastEffect 不为空:这种情况意味着这个组件有多个 useEffect,是第二个及其之后的 useEffect 会走到的分支,将 lastEffect 指向下一个 effect。

最后 return 一个 effect。

3.4 React Fiber 流程分析

看似源码到这里就结束了,但我们还存留几个问题没有解决:

  1. effect.tag 的那些二进制数是什么意思?
  2. pushEffect 之后还有什么逻辑?
  3. componentUpdateQueue 存储 Effect 之后会在哪里被用到?

renderWithHooks 中, componentUpdateQueue 会被赋值到 renderedWork.updateQueue 上,包括我们 3.2 中的 sideEffectTag 也会赋值到 renderedWork.effectTag 上。

renderedWork.updateQueue = (componentUpdateQueue: any);renderedWork.effectTag |= sideEffectTag;

在第 3 篇 4.3.1: renderWithHooks中,我们分析出 renderWithHooks 是在函数组件更新阶段( updateFunctionComponent)执行的函数,这里我们要想知道上面三个问题的答案,必须要把整个 Reconciler 的流程走一遍才能解析清楚。我个人认为 Fiber 是 React 16 中最复杂的一块逻辑了,所以在前面几篇中我只是略微提及,并没有展开篇幅解析。Fiber 里面的内容很多,如果展开的话足够写几篇文章了,因此这里也尽量简单快捷的走一遍流程,忽略本文不相关的细节,只梳理部分逻辑的实现,重点关注我们调用 useEffect 之后的逻辑。

注:如果对这部分不感兴趣的同学可以直接跳到 3.5 继续阅读。

React Fiber 优秀的文章有很多,这里再推荐阅读几篇文章和视频来帮助有兴趣的同学来了解

  1. A Cartoon Intro to Fiber - React Conf 2017
  2. React Fiber初探
  3. 这可能是最通俗的 React Fiber 打开方式

那我们开始吧!

3.4.1 ReactDOM.js

页面渲染的唯一入口便是 ReactDOM.render,

ReactRoot.prototype.render = ReactSyncRoot.prototype.render = function(  children: ReactNodeList,  callback: ?() => mixed,): Work {  // ... 忽略无关代码  updateContainer(children, root, null, work._onCommit);  return work;};

render 的核心是调用 updateContainer,这个函数来自于 react-reconciler 中的 ReactFiberReconciler.js。

3.4.2 ReactFiberReconciler.js

这个文件其实也是 react-reconciler 的入口,我们先看看 updateContainer 究竟是什么:

export function updateContainer(  element: ReactNodeList,  container: OpaqueRoot,  parentComponent: ?React$Component<any, any>,  callback: ?Function,): ExpirationTime {  // ... 忽略无关代码  return updateContainerAtExpirationTime(    element,    container,    parentComponent,    expirationTime,    suspenseConfig,    callback,  );}

忽略无关代码发现它其实只是 updateContainerAtExpirationTime 的一层封装,那我们看看这个是什么:

export function updateContainerAtExpirationTime(  element: ReactNodeList,  container: OpaqueRoot,  parentComponent: ?React$Component<any, any>,  expirationTime: ExpirationTime,  suspenseConfig: null | SuspenseConfig,  callback: ?Function,) {  // ... 忽略无关代码  return scheduleRootUpdate(    current,    element,    expirationTime,    suspenseConfig,    callback,  );}

再次忽略一些无关代码,发现它又是 scheduleRootUpdate 的一层封装……那我们再看看 scheduleRootUpdate 是什么:

function scheduleRootUpdate(  current: Fiber,  element: ReactNodeList,  expirationTime: ExpirationTime,  suspenseConfig: null | SuspenseConfig,  callback: ?Function,) {  // ... 忽略无关代码  enqueueUpdate(current, update);  scheduleWork(current, expirationTime);
  return expirationTime;}

忽略一小段无关代码,发现它的核心是做两件事, enqueueUpdate 我们这里暂时先不管,重点看看任务调度 scheduleWork,它相当于是 Fiber 逻辑的入口了,在 ReactFiberWorkLoop.js 中定义。

3.4.3 ReactFiberWorkLoop.js - render

ReactFiberWorkLoop.js 的内容非常长,有 2900 行代码,是包含任务循环主逻辑,不过我们刚才弄清楚要从 scheduleWork 开始着手那就慢慢梳理:

export function scheduleUpdateOnFiber(  fiber: Fiber,  expirationTime: ExpirationTime,) {  // ... 忽略无关代码  const priorityLevel = getCurrentPriorityLevel();
  if (expirationTime === Sync) {    if (      (executionContext & LegacyUnbatchedContext) !== NoContext &&      (executionContext & (RenderContext | CommitContext)) === NoContext    ) {      schedulePendingInteractions(root, expirationTime);      let callback = renderRoot(root, Sync, true);      while (callback !== null) {        callback = callback(true);      }    } else {      scheduleCallbackForRoot(root, ImmediatePriority, Sync);      if (executionContext === NoContext) {        flushSyncCallbackQueue();      }    }  } else {    scheduleCallbackForRoot(root, priorityLevel, expirationTime);  }  // ... 忽略特殊情况的处理}export const scheduleWork = scheduleUpdateOnFiber;

其实这段代码大部分分支都会收回到 renderRoot 上,再对 renderRoot 的回调做 while 循环处理。所以我们与其说 scheduleWork 是 Fiber 逻辑的入口,不如说 renderRoot 是入口。renderRoot 就是大名鼎鼎的 Fiber 两个阶段中的 render 阶段。

图源 A Cartoon Intro to Fiber - React Conf 2017

其实 debug 一下也容易看出这两个阶段:

renderRoot 中的代码也非常复杂,我们重点关注和本文有关的逻辑:

function renderRoot(  root: FiberRoot,  expirationTime: ExpirationTime,  isSync: boolean,): SchedulerCallback | null {  if (isSync && root.finishedExpirationTime === expirationTime) {    // There's already a pending commit at this expiration time.    return commitRoot.bind(null, root); // 进入 commit 阶段  }  // ...  do {    try {      if (isSync) {        workLoopSync();      } else {        workLoop(); // 核心逻辑      }      break;    } catch (thrownValue) {      // ...  } while (true);  // ...}

把一些多余的代码略去之后,我们关注到两个重要的点:

  1. workLoop 是代码的核心部分,配合循环来实现任务循环。
  2. 在超时的情况下,会进入 commit 阶段。

我们先看看 workLoop 的逻辑:

function workLoop() {  while (workInProgress !== null && !shouldYield()) {    workInProgress = performUnitOfWork(workInProgress);  }}

看来我们重点是需要看看 performUnitOfWork:

function performUnitOfWork(unitOfWork: Fiber): Fiber | null {  const current = unitOfWork.alternate;
  // ... 忽略计时逻辑
  let next;  if (enableProfilerTimer && (unitOfWork.mode & ProfileMode) !== NoMode) {    next = beginWork(current, unitOfWork, renderExpirationTime);  } else {    next = beginWork(current, unitOfWork, renderExpirationTime);  }
  // ... 忽略特殊逻辑
  ReactCurrentOwner.current = null;  return next;}

我们忽略计时逻辑,发现这段代码的内容其实就是两个 beginWork(这里解答了我们在第3篇中 4.3.1 中留下的问题)。这个 beginWork 引自 ReactFiberBeginWork.js。

3.4.4 ReactFiberBeginWork.js

本节代码分析同 第 3 篇 4.3.1: renderWithHooks,不再赘述。

也就是现在我们 renderedWork 上的 updateQueue(还记得它吗?它的内容是 Effect 链表) 和 effectTag 挂到了 Fiber 上,跳过这部分逻辑,我们看看 Fiber 最后怎么处理它们。

3.4.5 ReactFiberWorkLoop.js - commit

在刚才分析 renderRoot 的过程中,我们关注到任务超时之后会直接进入 commit 阶段。我们先看看 commitRoot 的代码:

function commitRoot(root) {  const renderPriorityLevel = getCurrentPriorityLevel();  runWithPriority(    ImmediatePriority,    commitRootImpl.bind(null, root, renderPriorityLevel),  );  return null;}

好的,这里发现我们应该关注 commitRootImpl,来看看:

function commitRootImpl(root, renderPriorityLevel) {
  // ...  startCommitTimer();
   // Get the list of effects.  let firstEffect;  if (finishedWork.effectTag > PerformedWork) {    if (finishedWork.lastEffect !== null) {      finishedWork.lastEffect.nextEffect = finishedWork;      firstEffect = finishedWork.firstEffect;    } else {      firstEffect = finishedWork;    }  } else {    firstEffect = finishedWork.firstEffect;  }
  if (firstEffect !== null) {    do {      try {        commitBeforeMutationEffects();      } catch (error) {        invariant(nextEffect !== null, 'Should be working on an effect.');        captureCommitPhaseError(nextEffect, error);        nextEffect = nextEffect.nextEffect;      }    } while (nextEffect !== null);    stopCommitSnapshotEffectsTimer();
    if (enableProfilerTimer) {      // Mark the current commit time to be shared by all Profilers in this      // batch. This enables them to be grouped later.      recordCommitTime();    }
    // The next phase is the mutation phase, where we mutate the host tree.    startCommitHostEffectsTimer();    nextEffect = firstEffect;    do {      try {        commitMutationEffects(root, renderPriorityLevel);      } catch (error) {        invariant(nextEffect !== null, 'Should be working on an effect.');        captureCommitPhaseError(nextEffect, error);        nextEffect = nextEffect.nextEffect;      }    } while (nextEffect !== null);    stopCommitHostEffectsTimer();    resetAfterCommit(root.containerInfo);
    // The work-in-progress tree is now the current tree. This must come after    // the mutation phase, so that the previous tree is still current during    // componentWillUnmount, but before the layout phase, so that the finished    // work is current during componentDidMount/Update.    root.current = finishedWork;
    // The next phase is the layout phase, where we call effects that read    // the host tree after it's been mutated. The idiomatic use case for this is    // layout, but class component lifecycles also fire here for legacy reasons.    startCommitLifeCyclesTimer();    nextEffect = firstEffect;    do {      try {        commitLayoutEffects(root, expirationTime);      } catch (error) {        invariant(nextEffect !== null, 'Should be working on an effect.');        captureCommitPhaseError(nextEffect, error);        nextEffect = nextEffect.nextEffect;      }    } while (nextEffect !== null);    stopCommitLifeCyclesTimer();
    nextEffect = null;
    // Tell Scheduler to yield at the end of the frame, so the browser has an    // opportunity to paint.    requestPaint();
    if (enableSchedulerTracing) {      __interactionsRef.current = ((prevInteractions: any): Set<Interaction>);    }    executionContext = prevExecutionContext;  } else {    // No effects.    // ...  }
  stopCommitTimer();
  nextEffect = firstEffect;  while (nextEffect !== null) {    const nextNextEffect = nextEffect.nextEffect;    nextEffect.nextEffect = null;    nextEffect = nextNextEffect;  }
  // ...
  return null;}

commitRootImpl 的代码是真的很长,我这里忽略了一些和 effect 处理无关的代码,剩下我们阅读一下,发现当 effect 存在的时候,有三段逻辑要处理,它们的逻辑基本相同,循环 effect 链表传给三个不同的函数,分别是:

  • commitBeforeMutationEffects
  • commitMutationEffects
  • commitLayoutEffects

最后将循环 effect,将 nextEffect 赋值成 nextNextEffect。

限于篇幅问题,且第三个函数关于 useLayoutEffect,所以左右这里这三个函数我们这里都不一一展开解释了,留给下篇文章中分析 useLayoutEffect 再来详解。所以 3.4 中我们留下的问题—— effect.tag 的那些二进制数是什么意思?这个问题也需要等到下一篇文章中来解释了。

我们这里只需要知道这三个函数的核心代码分别引用了 ReactFiberCommitWork.js 中的 commitWorkcommitBeforeMutationLifeCyclescommitLifeCycles,而这三个函数的核心代码在处理 FunctionCompoment 的逻辑时都走到了 commitHookEffectList 中即可。

3.5 commitHookEffectList

分析了一大圈,最后我们看看 ReactFiberCommitWork.js 中 commitHookEffectList 的逻辑,这里便是 useEffect 终点了:

function commitHookEffectList(  unmountTag: number,  mountTag: number,  finishedWork: Fiber,) {  const updateQueue: FunctionComponentUpdateQueue | null = (finishedWork.updateQueue: any);  let lastEffect = updateQueue !== null ? updateQueue.lastEffect : null;  if (lastEffect !== null) {    const firstEffect = lastEffect.next;    let effect = firstEffect;    do {      if ((effect.tag & unmountTag) !== NoHookEffect) {        // Unmount        const destroy = effect.destroy;        effect.destroy = undefined;        if (destroy !== undefined) {          destroy();        }      }      if ((effect.tag & mountTag) !== NoHookEffect) {        // Mount        const create = effect.create;        effect.destroy = create();      }      effect = effect.next;    } while (effect !== firstEffect);  }}

可以发现,这里的代码很清楚,这里把 renderedWork.updateQueue 上的 effect 取了下来,在 unmount 的时候执行 effect.destory(也就是 useEffect 第一个参数的返回值),在 mount 的时候执行 effect.create(也就是 useEffect 传入的第一个参数)。并且,循环所有的 effect 直到结束。

同时这里也印证了我们之前的猜想:当 tag 是 NoHookEffect 的时候什么也不做。

这里我们把 useEffect 的源码解释清楚了,但是遗留了一个问题:effect.tag 这个参数究竟有什么用?目前我们仅仅知道当它是 NoHookEffect 时的作用是不执行 useEffect 的内容,但是其他的值我们还没有分析到,它们分析逻辑主要在我们 3.4.5 略过的那三个函数里。在下篇文章中,我们分析 useLayoutEffect 中会拿出来详细分析。

大家再见。

最后附上 3.4 节分析的流程图:

文章分享自微信公众号:
QQ音乐前端团队

本文参与 腾讯云自媒体分享计划 ,欢迎热爱写作的你一起参与!

作者:Airing
原始发表时间:2019-12-15
如有侵权,请联系 cloudcommunity@tencent.com 删除。
登录 后参与评论
0 条评论

相关文章

  • 【useEffect原理】源码调试吃透REACT-HOOKS(二)

    大家好,我是心锁,一枚23届准毕业生。 上一章,我们了解了hook是怎么赋予函数式组件状态的,也同时借此了解与调试了useState的源码,而这次,我们要动手了...

    源心锁
  • 超性感的React Hooks(四):useEffect

    这里有一段介绍useEffect的文字,如果你能够从中领悟到useEffect的用法,那么恭喜你,你应该大概率是个天赋型选手。

    用户6901603
  • react源码解析13.hooks源码

    ​ 在hook源码中hook存在于Dispatcher中,Dispatcher就是一个对象,不同hook 调用的函数不一样,全局变量ReactCurrentDi...

    全栈潇晨
  • react源码解析13.hooks源码

    ​ 在hook源码中hook存在于Dispatcher中,Dispatcher就是一个对象,不同hook 调用的函数不一样,全局变量ReactCurrentDi...

    zz1998
  • React Hooks 学习笔记 | useEffect Hook(二)

    一般大多数的组件都需要特殊的操作,比如获取数据、监听数据变化或更改DOM的相关操作,这些操作被称作 “side effects(副作用)”。

    前端达人
  • 【React Hooks 专题】useEffect 使用指南

    Hooks 是 React 16.8 的新增特性,至今经历两年的时间,它可以让你在不编写 class 组件的情况下使用 state 以及其他 React 特性。...

    清秋
  • React Hooks 源码解析(3):useState

    React 源码版本: v16.11.0 源码注释笔记:airingursb/react 在写本文之前,事先阅读了网上了一些文章,关于 Hooks 的源码解...

    QQ音乐前端团队
  • React Hooks笔记:useState、useEffect和useLayoutEffect

    useState 让函数组件也可以有 state 状态,并进行状态数据的读写操作。

    德顺
  • 【React】883- React hooks 之 useEffect 学习指南

    如果你不想阅读整篇文章,可以快速浏览这份摘要。要是某些部分不容易理解,你可以往下滚动寻找相关的内容去阅读。

    pingan8787
  • react源码解析14.手写hooks

    最关键的是要理解hook队列和update队列的指针指向和updateQueue的更新计算,详细见视频讲解

    zz1998
  • react源码解析14.手写hooks

    最关键的是要理解hook队列和update队列的指针指向和updateQueue的更新计算,详细见视频讲解

    全栈潇晨
  • 全网最简单的React Hooks源码解析!

    从React Hooks发布以来,整个社区都以积极的态度去拥抱它、学习它。期间也涌现了很多关于React Hooks 源码解析的文章。本文就以笔者自己的角度来写...

    Nealyang
  • [译] React Hooks 底层解析

    原文:https://medium.com/the-guild/under-the-hood-of-reacts-hooks-system-eb59638c9d...

    江米小枣

扫码关注腾讯云开发者

领取腾讯云代金券