React的事件系统是怎么运作起来的？

本节目标：理解“React的事件系统是怎么运作起来的？”的核心思路，并能把它用于实际开发或面试表达。

说明：原 OneNote 中有图片引用，但图片未包含在导出目录中；本页保留了可用的文字与代码内容。 事件绑定 我们来看一下我们在JSX中写的

onClickhandler

是怎么被记录到DOM结点上，并且在document上做监听的。

React对于大部分事件的绑定都是使用trapBubbledEvent和trapCapturedEvent这两个函数来注册的。如上图所示，当我们执行了render或者setState之后，React的Fiber调度系统会在最后commit到DOM树之前执行trapBubbledEven或trapCapturedEvent， 通过执行addEventListener在document结点上绑定对应的dispatch作为handler负责监听类型为topLevelType的事件。 这里面的dispatchInteractiveEvent和dispatchEvent两个回调函数的区别为，React16开始换掉了原本Stack Reconciliation成Fiber希望实现异步渲染（目前仍未默认打开，仍需使用unstable_开头的api，此特性与例子2有关，将在文章最后配图解释），所以异步渲染的情况下加入我点了两次按钮，那么第二次按钮响应的时候，可能第一次按钮的handlerA中调用的setState还未最终被commit到DOM树上，这时需要把第一次按钮的结果先给flush掉并commit到DOM树，才能够保持一致性。这个时候就会用到dispatchInteractiveEvent。可以理解成dispatchInteractiveEvent在执行前都会确保之前所有操作都已最总commit到DOM树，再开始自己的流程，并最终触发dispatchEvent。但由于目前React仍是同步渲染的，所以这两个函数在目前的表现是一致的，希望React17会带给我们默认打开的异步渲染功能。 到现在我们已经在document结点上监听了事件了，现在需要来看如何将我们在jsx中写的handler存起来对应到相应的结点上。 在我们每次新建或者更新结点时，React最终会调用createInstance或者commitUpdate这两个函数，而这两个函数都会最终调用updateFiberProps这个函数，将props也就是我们的onClick，onChange等handler给存到DOM结点上。 至此，我们我们已经在document上监听了事件，并且将handler存在对应DOM结点。接下来需要看React怎么监听并处理浏览器的原生事件，最终触发对应的handler了。 事件触发 这里我做了个动画，希望能够对你们理解有帮助。点击绿色的按钮\>播放下一步。 抱歉需要插入链接，掘金不允许插入iframe。 以简单的click事件为例，通过事件绑定我们已经在document上监听了click事件，当我们真正点击了这个按钮的时候，原生的事件是如何进入React的管辖范围的？如何合成SyntheticEvent以及如何模拟捕获和冒泡的？以及最后我们在jsx中写的

onClickhandler

是如何被最终触发的？带着这些问题，我们一起来看一下事件触发阶段。 我会大概用下图这种方式来解析代码，左边是我点击一个绑定了handleClick的按钮后的js调用栈，右边是每一步的代码，均已删除部分不影响理解的代码。希望通过这种方式能使大家更易理解React的事件触发机制。

当我们点击一个按钮是，click事件将会最终冒泡至document，并触发我们监听在document上的handler dispatchEvent，接着触发batchedUpdates。batchedUpdates这个格式的代码在React的源码里面会频繁的出现，基本上React将所有能够批量处理的事情都会先收集起来，再一次性处理。 可以看到默认的isBatching是false的，当调用了一次batchedUpdates，isBatching的值将会变成true，此时如果在接下来的调用中有继续调用batchedUpdates的话，就会直接执行

handleTopLevel,

此时的setState等不会被更新到DOM上。直到调用栈重新回到第一次调用batchedUpdates的时候，才会将所有结果一起flush掉（更新到DOM上）。

有的同学可能问调用栈中的BatchedUpdates$1是什么？或者浏览器的renderer和Native的renderer是如果挂在到React的事件系统上的? 其实React事件系统里面提供了一个函数setBatchingImplementation，用来动态挂载不同平台的renderer，这个也体现了React事件系统的复用。 这里的interactiveUpdates和batchedUpdates的区别在上文已经解释过，这里就不再赘述。

handleTopLevel会调用runExtractedEventsInBatch()，这是React事件处理最重要的函数。如上面动画我们看到的，在EventEmitter里面做的事，其实主要就是这个函数的两步。

• 第一步是根据原生事件合成合成事件，并且在vDOM上模拟捕获冒泡，收集所有需要执行的事件回调构成回调数组。
• 第二步是遍历回调数组，触发回调函数。

首先调用extractEvents，传入原生事件e，React事件系统根据可能的事件插件合成合成事件Synthetic e。 这里我们可以看到调用了EventConstructor.getPooled()，从事件池中去取一个合成事件对象，如果事件池为空，则新创建一个合成事件对象，这体现了React为了性能实现了池的思想。

然后传入Propagator，在vDOM上模拟捕获和冒泡，并收集所有需要执行的事件回调和对应的结点。traverseTwoPhase模拟了捕获和冒泡的两个阶段，这里实现很巧妙，简单而言就是正向和反向遍历了一下数组。接着对每一个结点，调用listenerAtPhase取出事件绑定时挂载在结点上的回调函数，把它加入回调数组中。

接着遍历所有合成事件。这里可以看到当一个事件处理完的时候，React会调用event.isPersistent()来查看这个合成事件是否需要被持久化，如果不需要就会释放这个合成事件，这也就是为什么当我们需要异步读取操作一个合成事件的时候，需要执行event.persist()，不然React就是在这里释放掉这个事件。

最后这里就是回调函数被真正触发的时候了，取出回调数组event._dispatchListeners，遍历触发回调函数。并通过event.isPropagationStopped()这一步来模拟停止冒泡。这里我们可以看到，React在收集回调数组的时候并不会去管我们是否调用了stopPropagation，而是会在触发的阶段才会去检查是否需要停止冒泡。 至此，一个事件回调函数就被触发了，里面如果执行了setState等就会等到调用栈弹回到最低部的interactiveUpdate中的被最终flush掉，构造vDOM，和好，并最终被commit到DOM上。 这就是事件触发的整个过程了，可以回去再看一下动画，相信你会更加理解这个过程的。 例子Debug 现在我们对React事件系统已经比较熟悉了，回到文章开头的那两个玄学问题，我们来看一下到底为什么?例子一 如果想看题目内容或者忘记题目了，可以点击这里查看。 相信看完这篇文章，如果你已经对React事件系统有所理解，这道题应该是不难了。

1. 因为React事件监听是挂载在document上的，所以原生系统在#outer上监听的回调C会最先被输出；接着原生事件冒泡至document进入React事件系统，React事件系统模拟捕获冒泡输出A和B；最后React事件系统执行完毕回到浏览器继续冒泡到window，输出D。
2. 原生系统在#outer上监听的回调C会最先被执行；接着原生事件冒泡至document进入React事件系统，输出A，在React事件处理中#inner调用了stopPropagation，事件被停止冒泡。

所以，最好不要混用React事件系统和原生事件系统，如果混用了，请保证你清楚知道会发生什么。

例子二 如果想看题目内容或者忘记题目了，可以点击这里查看。 这个问题就稍微复杂一点。首先我们点击edit按钮浏览器触发一个click事件，冒泡至document进入React事件系统，React执行回调调用setState，此时React事件系统对事件的处理执行完毕。由于目前React是同步渲染的，所以接着React执行performSyncWork将该button改成type="submit"，由于同个位置的结点并且tag都为button，所以React复用了这个button结点(具体原因可以参考)并更新到DOM上。此时浏览器对click事件处理执行继续，发现该结点的type="submit"，又在form下面，则对应触发submit事件。 解决的办法就有很多种了，给button加上key；两个按钮分开写，不要用三元等都可以解决问题。 具体可以看一下下面的这个调用图，应该也很好理解，如果有不能理解的地方，请在下面留言，我会尽我所能解释清楚。

额外多说一个点，“setState是异步的” 相信对于很多React开发者来说，“setState是异步的”这句话应该经常听到，我记得我一开始学习React的时候经常就会看到这句话，然后说如果需要用到之前的state需要在setState中采用setState((preState)=\>{})这样的方式。 但其实这句话并不是完全准确的。准确的说法应该是setState有时候是异步的，setState相对于浏览器而言是同步的 目前而言setState在生命周期以及事件回调中是异步的，也就是会收集起来批量处理。在其它情况下如promise，setTimeout中都是同步执行的，也就是调用一次setState就会render一次并更新到DOM上面，不信的话可以点击这里尝试。 且在JS调用栈被弹空时候，必定是已经将结果更新到DOM上面了（同步渲染）。这也就是setState相对于浏览器是同步的含义。如下图所示

异步渲染的流程图大概如下图所示，最近一次思考这个问题的时候，发现如果现在是异步渲染的话，那我们的例子二将变成偶现的坑😂，因为如果setState的结果还没被更新到DOM上，浏览器就不会触发submit事件。 不过React团队已经为异步渲染的愿景开发了两年，且React16中已经采用了Fiber reconciliation和提供了异步渲染的api unstable_xxx，相信在React17中我们可以享受到异步渲染带来的性能提升，感谢React团队。 总结 希望读完此文，能让你React事件系统有个简单的认识。知道“为什么React需要自己实现一套事件系统？”和“React的事件系统是怎么运作起来的？”。React为了性能和复用，采用了事件代理，池，批量更新，跨浏览器和跨平台兼容等思想，将事件监听挂载在document上，并且构造合成事件，并且在内部模拟了一套捕获和冒泡并触发回调函数的机制，实现了自己一套事件系统。 如果你还有哪里不清楚，发现文章有错漏，或是单纯的交流相关问题，请在下面留言，我会尽我所能回复和解答你的疑问的。 如果你喜欢我的文章，请关注我和我的博客，谢谢。 Read More & Reference

• 推荐！React events in depth w/ Kent C. Dodds, Ben Alpert, & Dan Abramov

• 推荐！The React and React Native Event System Explained: A Harmonious Coexistence

•   Didact Fiber: Incremental reconciliation

•   Codebase Overview

> 来自

 <https://juejin.im/post/5bdf0741e51d456b8e1d60be>