【React】React进阶(源码及实现原理)

React进阶(源码及实现原理)

    • 一 基础篇
      • JSX是React.createElement的语法糖。
      • 虚拟DOM
      • diff和调和
      • React15的diff过程
      • 组件化
      • 生命周期的本质
    • 二 进阶篇
      • React16生命周期
      • Fiber
      • ReactDOM.render
        • 1.初始化init阶段
        • 2.render阶段
        • 3.commit阶段
      • 双缓冲模式。
      • React事件的实现


一 基础篇

JSX是React.createElement的语法糖。

React.createElement将会返回一个叫做“ReactElement”的JS对象

createElement 参数:

createElement(type,config,children)

type,用于标识节点的类型

config,以对象形式转入,组件所有的属性都会以键值对的形式存储在config对象中

children,以对象形式传入,它记录的是组件标签之间的嵌套内容

React.createElement函数体拆解

首先 二次处理key,ref,self,source四个属性值,再遍历config,筛选出可以给到props里的属性,接着提取子元素,给到childArray也就是props.children数组,最后格式化defaultProps ,结合上面处理完的数据作为入参,发起ReactElement调用。

ReactDom.render(element,container,[callback])

虚拟DOM

本质上是JS和DOM之间的一个映射缓存,在形态上表现为一个能够描述DOM结构及其属性信息的JS对象。

虚拟DOM的生成又分为组件创建和组件更新两个阶段

组件创建时React结合JSX描述构建出DOM树,ReactDOM。render实现生成虚拟DOM,实现虚拟与真实DOM之间的映射,接着触发渲染的线程。

组件更新时,页面变化首先作用于虚拟DOM,调用render方法去生成新的虚拟DOM,接着通过diff算法定位出两个虚拟DOM的不同,再讲这些改变作用于真实DOM。

虚拟DOM的劣势主要在于JS计算的耗时,DOM操作的能耗比JS计算的能耗要高很多。

虚拟DOM的价值不仅仅在于性能,同时提升了开发者的体验和效率,从之前的直接操作真实DOM到了通过书写JS编写虚拟DOM,符合数据驱动视图这一点,同时也解决了跨平台的问题,批量更新时,在虚拟DOM库里由batch函数处理,batch的作用是缓冲每次生成的补丁集。

diff和调和

指的是对比出两颗虚拟DOM树之间差异的过程,不同框架不同版本可能都有着不同的实现思路。

调和和diff,调和 虚拟DOM是一种编程概念,UI以一种虚拟的表现形式保存在内存中,并通过ReactDOM等类库使之与真实DOM同步,这个过程叫做协调或调和。

调和和diff并不是一个概念,调和是使一致的过程,而diff则是负责找不同的过程。

React可以大致的分为三个部分:

Core、Reconciler和Renderer。

而Reconciler也就是调和器是React较为重要的一部分。

调和器负责组件的挂载,卸载,更新等过程,但在面试或者技术交流中,一般认为调和就指的diff,因为diff是调和过程中最具代表性的一环。

diff的设计思想:

1.若两个组件属于同一个类型,它们将拥有相同的DOM树形结构。

2.处于同一层级的一组子节点,可用通过设置key作为唯一标识从而维持各个节点在不同渲染过程中的稳定性。

逻辑拆分:

diff算法性能突破的关键点在于分层比较,类型一致的节点才会继续diff,设置key属性,尽可能的重用一个层级内的节点。

总结以下几点:

1.diff过程只针对于相同层级的节点作比较

2.diff过程只对比相同类型的组件。

3.key属性维护节点的稳定性,用来帮助React识别哪些内容被修改,如果key值改变就会重新渲染UI。

React15的diff过程

批量更新:树递归。

setState时,调和器会把它塞到一个队列中,等执行完这个队列时,仅对最新的state执行一次更新流程,这时体现出来的setState就是异步的,但把setState放到settimeout中,setState又是同步的。

那么setState到底是同步还是异步的呢,让我们直接进入setState的工作流。

在setState后,首先调用的是enqueueSetState这个方法,再去调用enqueueUpState方法,最后通过isBatchingUpdates去判断是入队列还是直接执行。

setState:

ReactComponent.prototype.setState = function(partialState, callback) {
    this.updater.enqueueSetState(this, partialState);
	if (callback){
		this.updater.enqueueCallback(this, callback, 'setState');
	}
}

enqueueSetState:

function enqueueSetState(publiclnstance, partialState) {
    var queue = internalInstance._pendingStateQueue | l(internallnstance._pendingStateQueue = D); 		queue.push(partialState);
    enqueueUpdate(internalInstance)
}

enqueueUpState://组件实例

function enqueueUpdate(component) {
    ensurelnjected();
   if(!batchingStrategy.isBatchingUpdates){
       //立即执行
        batchingStrategy.batchedUpdates(enqueueUpdate, component); return;
   }
    	//等待
     dirtyComponents.push(component);
    if (component._updateBatchNumber == null) {
        component._updateBatchNumber = updateBatchNumber + 1;
    }
}

isBatchingUpdates:

//全局锁
var ReactDefaultBatchingStrategy = {
    isBatchingUpdates: false,
    batchedUpdates: function(callback, a, b, c, d, e) {}
}

判断是否立即执行:

var alreadyBatchingStrategy = ReactDefaultBatchingStrategy.isBatchingUpdates
ReactDefaultBatchingStrategy.isBatchingUpdates = true
if (alreadyBatchingStrategy) {
    callback(a, b, c, d, e)
} else {
    transaction.perform(callback, null, a, b, c, d, e)
}

setState本质上是由React事务机制和批量更新机制来控制的,是通过isBatchingUpdates这个变量来控制是否是异步更新。

在源码中体现为Transaction这样一个核心类,是一个可以封装任何方法的盒子。

事件监听部分源码:

function(topLevelType, nativeEvent) {
    ...
  try {
    ReactUpdates.batchedUpdates(handleTopLevellmpl, bookKeeping);
  } finally {
    TopLevelCallbackBookKeeping.release(bookKeeping);
  }
}

组件化

工程化思想在框架中的实现,既有能提现封闭的地方,也有能提现出开放的地方

针对于渲染工作流来说是封闭的,在组件自身的渲染工作流中,每个组件都只处理它内部的渲染逻辑。

针对于组件间的通讯来说是开放的,react允许开发者基于单向数据流的原则,完成组件间的通讯。

生命周期的本质

渲染工作流:指的是从组件数据改变到组件实际更新发生的过程。

render在执行过程中并不会去操作真实DOM,它的职能是把需要渲染的内容返回出来。

componentDidMount方法在渲染结束后被触发,可以操作真实DOM。

父组件导致组件重新渲染,即使props没有更改,也会调用componentReceiveProps。

二 进阶篇

React16生命周期

为什么在高阶中写这个,因为在项目开发中,还是有很多有经验的React开发者们习惯的用componentWillReceiveProps这个旧的生命周期,因为render阶段是可以被打断的,使用这个生命周期有导致很多不可预测的风险出现,所以大家以后开发时尽可能的不要使用componentWillReceiveProps这个生命周期,转而使用getDerivedStateFromProps和componentDidUpdate。

getDerivedStateFromProps只能用来通过props来更新或生成state。

getDerivedStateFromProps是一个静态方法,就代表着在方法体里不可以使用this,并且需要通过static声明这个方法。

该方法接收两个参数,第一个是props,第二个是state,而第一个参数是接受到的最新的props,第二参数是之前的state,所以在方法的形参中,我们可以使它更语义化一点,第一个形参命名为nextProps,第二个形参命名为prevState。

该方法需要返回一个对象格式的返回值,返回值为更新的state,对state的更新并非全量更新,而是增量更新,只针对于某个属性定向更新。

Fiber

浏览器是多线程的,JS是单线程的,渲染线程和JS线程同时执行的话会导致不可预测的结果,所以它们运行流程必须是互斥的。

当JS线程占用主线程太长时间时,渲染层面的更新长时间地等待,界面不更新,带给用户就是卡顿的感觉,同时事件线程也在等待JS,就导致触发的事件也是不会被相应的,而在16之前的版本使用的Stack Reconciler也就是React16之前的调和器又是同步的递归的过程,它会重复的调用父组件调用子组件的过程知道最深的节点更新完毕,才会向上返回,导致一个长时间占用线程的事件无法被打断,所以的事件都必须等待他执行完成。React 16.x版本后的调和器Fiber Reconciler的作用之一就是同步的渲染过程变成异步的,而且这个异步渲染模式是可以被打断的,将一个大的任务拆解为多个小任务,这样就很好的解决了这个问题,但这只是其中的一种作用。

Fiber架构的核心有以下几点:可中断,可恢复,优先级。

fiber是比线程还要纤细的一个过程,意在对渲染过程实现更加精细的控制,fiber节点保存了组件需要更新的状态和副作用,同时实现了增量渲染,这样就可以实现任务的可中断,可恢复并且给不同任务赋予优先级,以此达到我们需要的效果。

那么Fiber对生命周期有什么影响呢。

React 16之前在render阶段和commit阶段之间的同步递归计算,在React 16 中被划分为了一个个的工作单元也就是fiber这个数据结构,他们是可以根据优先级来进行异步,可中断可恢复的。

ReactDOM.render

接下来将深入渲染挂载到页面上时React究竟做了哪些事情。

ReactDOM.render会经历三个阶段。

1.初始化init阶段

完成基本实体的创建

初始化时调用legacyCreateRootFromDOMContainer创建container.reactRootContainer对象并赋值给root,其次将root上的_inernalRott属性赋值给fiberRoot,再者将fiberRoot与方法入参一起,传入updateContainer方法中,形成回调,最后将updateContainer回调作为参数传入,调用unbatchedUpdates,

fiberRoot:

【React】React进阶(源码及实现原理)_第1张图片

fiber节点:

【React】React进阶(源码及实现原理)_第2张图片

fiberRoot对象实例化为rootFiber也就是FiberNode实例。

unbatchUpdates阶段时会请求当前fiber节点的优先级lane,结合lane创建当前fiber节点的update对象,并将其入队调度当前节点rootFiber。

performSyncWorkOnRoot是render阶段的起点,render阶段的任务就是完成Fiber树的构建,它是整个渲染链路中最核心的一环。

在int阶段后,React就要开始启动了,而现在存在三种React启动方式。

legacy模式:ReactDOM.render(,rootNode)

blocking模式:ReactDOM.createBlockingRoot(rootNode).render()

concurrent模式:ReactDOM.createRoot(rootNode).render()

Legacy可能不支持新功能

blocking是过渡模式

默认为concurrent,最新,目前在v18.0.0-alpha,和experiment版本中发布. 这个模式开启了所有的新功能。

如果需要异步渲染,则需要调用ReactDOM.createRoot方法来启动应用。

mode属性的差异会导致Lane是SyncLane时,进行异步渲染。

既然Fiber解决了异步渲染的问题,那Fiber架构一定是异步渲染吗。

从设计层面来看Fiber架构确实是为了Concurrent也就是异步渲染模式而设计的,但Fiber架构在React中并不能和异步渲染完全相等,它兼容了同步与异步渲染。

2.render阶段

是整个渲染链路中最为核心的一环,找不同也就是更新的过程就是在render阶段发生的。

React15下的调和过程是递归的形式,在ReactDOM.render触发的同步模式下,它是一个深度优先搜索的过程,在这个过程中,beginWork将创建新的Fiber节点,而completeWork则负责将Fiber节点映射为DOM节点。

workInProgress节点的创建:

//current是现有树结构中的rootFiber对象
function createWorklnProgress(current, pendingProps) {
    //current的alternate将反过来指向workInProgress
    var workInProgress = current.alternate;
    if (worklnProgress === null) {
       //后面createWorklnProgress调用createFiber
        workInProgress = createFiber(current.tag, pendingProps, current.key, current.mode);
        worklnProgress.elementType = current.elementType;
        workInProgress.type = current.type;
        workInProgress.stateNode = current.stateNode;
        //workInProgress的alternate将指向current
        workInProgress.alternate = current;
        current.alternate = workInProgress;
    } else {
       //workInprogress是createFiber方法的返回值
        ...
        return workInProgress
    }
}

createFiber:

var createFiber = function(tag,pendingProps,key,mode){
    return new FiberNode(tage,pendingProps,key,mode)
}
workInProgress = createFiber(current.tag,pendingProps,current.key,current.mode)

workInProgress节点本质上是current节点也就是rootFiber的复制节点

新Fiber节点的创建:

function workLoopSync(){
    //判断workInProgress 是否为空
    while(workInProgress!==null){
        //触发beginWork,创建Fiber节点
        performUnitOfWork(workInProgress)
    }
}

从一开始说的current树,到现在的workInProgress树,好像是没有区别的,那么到底为什么要搞出两颗一样的树出来呢?这里是极大限度地实现Fiber节点的复用,涉及到双缓冲模式,后面详细探讨一下。

beginWork开启Fiber节点的创建,入参为current节点,workInProgress节点。

beginWork的核心逻辑是根据workInProgress的tag属性的不同调用不同的节点创建函数

function reconcileChildren(current, workInProgress, nextChildren, renderLanes) {
    if (current === null) {
        workInProgress.child = mountChildFibers(workInProgress, null, nextChildren, renderLanes);
    } else {
        workInProgress.child = reconcileChildFibers(workInProgress, current.child, nextChildren, renderLanes);
    }
}
var reconcileChildFibers = ChildReconciler(true)
var mountChildFibers = ChildReconciler(false);

ChildReconciler的返回值是一个名为reconcileChildFibers的函数,这个函数起到逻辑分发的作用,它根据入参不容,执行相应的Fiber节点操作,最终会返回不同的Fiber节点。

mountChildFibers和reconcileChildFibers不同在于入参不同,所以产生的副作用也不同,导致返回的Fiber节点也不同

用来标记创建DOM节点的函数:

function placeSingleChild(newFiber){
    if(shouldTrackSideEffects&&newFiber.alternate===null){
        newFiber.flags=Placement
    }
   	return newFiber
}

更新渲染时 placeSingleChild 会把新创建的 fiber 节点标记为 Placement, 待到提交阶段处理。

之前的版本中叫做effectTag,flags或者effectTag的意义就是标记这个fiber节点需要新建DOM节点,effectTag或flags标记的是副作用的类型。

接下来会进入这段代码来判断他的类型:

const isObject = typeof newChild === 'object' && newChild !== null;
if (isObject) {
    switch (newChild.$$typeof) {
        case REACT_ELEMENT_TYPE:
            return placeSingleChild(
                reconcileSingleElement( returnFiber,currentFirstChild,
                    newChild,
                    expirationTime,
                ),
            );
        case REACT_PORTAL_TYPE:
            return placeSingleChild(
                reconcileSinglePortal(
                    returnFiber,
                    currentFirstChild,
                    newChild,
                    expirationTime,
                ),
            );
    }
}
if (typeof newChild === 'string' || typeof newChild === 'number') {
    return placeSingleChild(
        reconcileSingleTextNode(
            returnFiber,
            currentFirstChild,
            '' + newChild,
            expirationTime,
        ),
    );
}
if (isArray(newChild)) {
    return reconcileChildrenArray(
        returnFiber,
        currentFirstChild,
        newChild,
        expirationTime,
    );
}
if (getIteratorFn(newChild)) {
    return reconcileChildrenIterator(
        returnFiber,
        currentFirstChild,
        newChild,
        expirationTime,
    );
}

然后FiberNode就会被赋予标记的类型,如下图。

【React】React进阶(源码及实现原理)_第3张图片

新建立的Fiber节点作为root Fiber的child属性建立起与workInprogress Fiber树的关联:

function workLoopSync(){
    while(workInProgress!==null){
        performUnitOfWork(workInProgress)
    }
}

新建Fiber节点:

next=beginWork$1(current,unitOfWork,subtreeRenderLanes)
if(next===null){
    completeUnitOfWork(unitOfWork)
}else{
    workInProgress=next
}

没有新建的节点后就会完成此次创建节点的过程。

循环创建Fiber节点。

那么Fiber节点是怎么建立关联的呢,是通过节点的三个属性,分别是child,return,sibling。child,return是用来记录父子节点关系的,sibling节点用来记录兄弟节点关系。

总结一下创建Fiber节点的流程。

beginWork=>处理rootFiber节点=>调用reconcileChildren创建子节点=>Current不为null时,会进入reconcileChildFibers,reconcileChildFibers是ChildReconciler(true)的返回值,副作用将会被追踪=>reconcileChildFibers将子节点创建逻辑分发给reconcileSingleElement得到返回值App FiberNode=>调用placeSingleChild会把新创建的 fiber 节点标记为 Placement=>新创建的 fiber 节点作为root Fiber的child属性,与现有的workInprogress Fiber树建立关联。

completeWork

什么情况会调用completeWork呢,当前Fiber节点结束了递归的过程也就是next===null了。之前提到过得beginWork负责创建Fiber节点,而completeWork负责将Fiber节点映射到DOM节点。

completeWork会做三件事。

1.创建DOM节点

2.将DOM节点插入DOM树中

3.设置DOM节点的属性

创建好的DOM节点会被赋值给workInProgress节点的stateNode属性

创建好DOM节点之后的操作是什么呢?是通过appendAllChildren函数来完成将DOM节点插入到DOM树中。

此时就遇到了一个问题,这个DOM节点应该如果添加到DOM树中,之前提到过节点的三个关系,其中这里就是通过父级的DOM节点添加到的DOM树中的,但如果没有父级的DOM,例如是第一个节点,要怎么添加到DOM树中,如果没有父级DOM节点就会作为Fiber节点的stateNode属性存在,然后进入到completeUnitOfWork针对传入的当前节点调用completeWork,并将当前节点的副作用插入到父节点的副作用链中,最后以此节点作为起点,去循环遍历其兄弟节点以及其父节点。

在确认没有待处理的兄弟节点后,才会处理父节点,因为completeWork执行是严格的自底向上的过程。

总结一下render阶段。

1.通过completeWork自底向上执行,找出需要更新的地方,workInProgress递归完毕,所有更新地方被找出。

2.节点创建effectList时并不是为了自己创建的而是为了父节点创建,因为completeWork是严格的自底向上执行的,进入创建effectList的逻辑时,当firstEffect与lastEffect指向同一个节点时,该节点就会成为effectList中的唯一的FiberNode。将所有需要更新的节点,通过链的方式连接起来,最后生成一条副作用链,就是整个render阶段的成果,这条副作用链中记录着所有需要更新的节点,节点等待挂载。。。render阶段结束。

3.commit阶段

commit节点一定是同步的。

commit的第一个阶段,before mutation,这个阶段还没有将DOM节点渲染到界面上去,该阶段遍历完整个effectList就结束了,遍历时对每个effect都进行了commitBeforeMutationEffects方法的调用

commit的第二个阶段,mutation,这个阶段负责DOM节点的渲染.

startCommitHostEffectsTimer();
nextEffect = firstEffect;
do {
  try {
      // renderPriorityLevel为优先级
      commitMutationEffects(renderPriorityLevel);
    } catch (error) {
      invariant(nextEffect !== null, 'Should be working on an effect.');
      captureCommitPhaseError(nextEffect, error);
      nextEffect = nextEffect.nextEffect;
    }
} while (nextEffect !== null);
stopCommitHostEffectsTimer();
function commitMutationEffects(renderPriorityLevel) {
  while (nextEffect !== null) {
    const effectTag = nextEffect.effectTag;

    if (effectTag & ContentReset) {
      // 清除文本节点内容及其子节点变为 ‘’
      commitResetTextContent(nextEffect);
    }

    // 将 ref 的指向置为 null
    if (effectTag & Ref) {
      const current = nextEffect.alternate;
      if (current !== null) {
        commitDetachRef(current);
      }
    }

    // The following switch statement is only concerned about placement,
    // updates, and deletions. To avoid needing to add a case for every possible
    // bitmap value, we remove the secondary effects from the effect tag and
    // switch on that value.

    // effect类型
    let primaryEffectTag = effectTag & (Placement | Update | Deletion);

    // 类型区分
    switch (primaryEffectTag) {
      case Placement: {
        commitPlacement(nextEffect);
        // Clear the "placement" from effect tag so that we know that this is
        // inserted, before any life-cycles like componentDidMount gets called.
        // TODO: findDOMNode doesn't rely on this any more but isMounted does
        // and isMounted is deprecated anyway so we should be able to kill this.
        // 执行完成后去掉 Placement 标记
        nextEffect.effectTag &= ~Placement;
        break;
      }
      case PlacementAndUpdate: {
        // Placement
        commitPlacement(nextEffect);
        // Clear the "placement" from effect tag so that we know that this is
        // inserted, before any life-cycles like componentDidMount gets called.
        nextEffect.effectTag &= ~Placement;

        // Update
        const current = nextEffect.alternate;
        commitWork(current, nextEffect);
        break;
      }
      case Update: {
        const current = nextEffect.alternate;
        commitWork(current, nextEffect);
        break;
      }
      case Deletion: {
        commitDeletion(nextEffect, renderPriorityLevel);
        break;
      }
    }

    // TODO: Only record a mutation effect if primaryEffectTag is non-zero.
    recordEffect();

    nextEffect = nextEffect.nextEffect;
  }
}

其中要注意的是

1.commitResetTextContent,这个方法是判断如果原来是文本节点变为不是文本节点了,就要使用DOM textContent 属性的值去掉原来的节点的值。

【React】React进阶(源码及实现原理)_第4张图片

以上图片转自

2.commitDetachRef 方法将当前 fiber 上的 ref 设置为 null,也就是解除了 ref 的关系

3.commitPlacement ,对新增节点的处理。通过原生的appendChild和insertBefore方法 。当插入的节点为类式组件时,首先会遍历这个组件,遍历方式和之前创建fiber节点的workLoopSync方法差不多,先根据 child 属性找到第一个原生节点,有兄弟节点就转到兄弟节点,兄弟节点有子节点就继续遍历子节点,没有就返回上级节点,一直到返回目标节点。

第三个阶段 layout,这个阶段处理DOM渲染完毕之后的逻辑,例如将之前解绑的current指针指向workInProgress Fiber树。

双缓冲模式。

双缓冲模式是不同的缓冲数据交替被读取后的结果,能较大限度的实现Fiber节点的复用,从而减少性能方面的开销。

current树与workInProgress树就是双缓冲模式下的两套缓冲数据,当current树呈现在用户眼前时,所有的更新都会由workInProgress树来承接。

接下来再看看异步渲染是怎么实现的。

这里要提到两个东西:

1.时间切片

2.优先级

同步渲染模式下的render阶段是一个同步,深度优先搜索的过程

1.时间切片:在异步渲染模式下,这个循环由workLoopConcurrent开启。

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

当shouldYield返回为true时就说明需要结束循环将空间给主线程了。

exports.unstable_shouldYield = function(){
    return exports.unstable_now() >= deadline
}
deadline = currentTime + yieldInterval

2.优先级:通过调用unstable_scheduleCallback来发起调度的,结合任务的优先级信息为其执行不同的调度逻辑。

function unstable_scheduleCallback(priorityLevel,callback,options){
    var currentTime = exports.unstable_now();
    var startTime
}
if(typeof options === 'object' && options !== null ){
    var delay = options.delay
}
if( typeof delay === 'number' && delay>0 ){
    startTime = currentTime + delay;
}else{
    startTime = currentTime;
}
else{
    startTime = currentTime
}

var timeout

//优先级实现
switch(priorityLevel){
    case ImmediatePriority:
        timeout = IMMEDIATE_PRIORITY_TIMEOUT
    break;
......        
}
var expirationTime = startTime + timeout ;

var newTask = {
    id : taskIdCounter++ ,
    callback : callback ,
    priorityLevel : priorityLevel ,
    startTime : startTime ,
    expirationTime : expirationTime ,
    sortIndex : -1 
}
if( startTime > currentTime ){
    newTask.sortIndex = startTime ;
    .....
}
if(peek(taskQueue) === null && newTask === peek(timer))

通过源码,可以得出优先级调度的实现方法:创建newTask对象;

通过startTIme和currentTime判断当前任务是否是过期任务,是过期任务则假如taskQueue堆中,再有requestHostCallback(flushwork)派发为及时任务。

不是过期任务则加入timerQueue堆或在哪个,再判断taskQueue是否为空,不为空则将当前的newTask返回,为空则判断newTask是否是timerQueue堆的最新的任务,是则调用requestHostTimeout派发延时的任务,不是则返回当前的newTask。

React事件的实现

W3C标准约定了一个事件的传播过程要经历一下三个阶段:

事件捕获阶段

目标阶段

事件冒泡阶段

DOM事件的性能优化思路:事件委托。

把多个子元素同一类型的监听事件放到父元素的监听事件中。

React事件系统是如何工作的。

当事件在具体的DOM节点上被触发后,最终都会冒泡到document上,document上所绑定的统一事件处理程序会将事件分发到具体的组件实例。

React合成事件,提供给了开发者统一的事件接口,但最终还是引用的原生DOM事件。

React合成事件会经历两个步骤,第一事件绑定,第二事件触发。

React的事件绑定是在completeWork中完成的,

completeWork有三个关键性的操作

1.创建DOM节点。

2.为DOM节点插入到DOM树中。

3.为DOM节点设置属性。

completeWork首先通过createInstance创建DOM节点,接着通过appendAllChildren将DOM节点插入DOM树中,然后通过finalizeInittialChildren设置DOM节点的属性,在finalizeInittialChildren之后会调用setInitialProperties去处理传入的props,然后调用setInitialDOMProperties方法去设置DOM节点的初始化属性,接着进入到事件监听的注册流程经过调用ensureListeningTo方法,到了分发事件监听的注册逻辑通过legacyListenToLevelEvent实现,再会进入到一段判断逻辑,判断事件是捕获还是冒泡,分别进入不同的处理逻辑后,都会回归到addTrappedEventListener上将事件注册到document上。

多次调用了对同一事件的监听,也只会在document上注册一次,因为React最终注册到document上的并不是一个节点的具体逻辑,而是一个事件分发函数,这个分发函数就是dispatchEvent。

那么React事件是如何触发的呢,本质是通过调用分发函数dispatchEvent,事件触发时会冒泡至document,紧接着会执行dispatchEvent,在创建完事件对应的合成事件对象syntheticEvent后,将收集event在捕获阶段的回调函数和对应的DOM节点实例,收集事件在冒泡阶段的回调函数和对应的DOM节点实例,将前两步收集来的回调按顺序执行。

function traverseTwoPhase(inst , fn , arg ){
    var path = [] ;
    
    while(inst){
        path.push(inst);
        inst = getParent(inst);
    }
    var i ;
    for( i = 0 ; i < path.length ; i++ ){
        fn( path[i] , 'bubbled' , arg );
    }
}

以上源码循环收集符合条件的父节点,存入到path中,tag === HostComponent的父节点中,并将这些节点按顺序收集进path数组中。

HostComponent是DOM元素对应Fiber节点类型,也就是只收集DOM元素对应的Fiber节点。

那么在原生事件中的冒泡与捕获在React事件中是如何实现的呢?

path数组中子节点在前,祖先节点在后,也就是父节点向下遍历子节点,直到遍历到目标节点,顺序和捕获阶段的传播顺序是一致的。traverseTwoPhase会从后向前遍历path数组模拟事件的冒泡事件,会收集事件在捕获阶段对应的回调与实例,他们唯一的区别是对path数组的倒叙遍历变成了正序遍历。

那么,为什么React要费这么大的精力去搞一套自己的事件接口呢,他的作用在于在开发层面统一了不同浏览器事情的差异,提供统一,稳定的事件接口,而且还有一个最重要的作用,帮助React实现对所有事件的集中管控。

以上源码循环收集符合条件的父节点,存入到path中,tag === HostComponent的父节点中,并将这些节点按顺序收集进path数组中。

HostComponent是DOM元素对应Fiber节点类型,也就是只收集DOM元素对应的Fiber节点。

那么在原生事件中的冒泡与捕获在React事件中是如何实现的呢?

path数组中子节点在前,祖先节点在后,也就是父节点向下遍历子节点,直到遍历到目标节点,顺序和捕获阶段的传播顺序是一致的。traverseTwoPhase会从后向前遍历path数组模拟事件的冒泡事件,会收集事件在捕获阶段对应的回调与实例,他们唯一的区别是对path数组的倒叙遍历变成了正序遍历。

那么,为什么React要费这么大的精力去搞一套自己的事件接口呢,他的作用在于在开发层面统一了不同浏览器事情的差异,提供统一,稳定的事件接口,而且还有一个最重要的作用,帮助React实现对所有事件的集中管控。

你可能感兴趣的:(react,reactjs,react.js,前端框架,前端)