已经有很多帖子解释了如何使用React的事件处理系统，但是并没有多少帖子是在解释他们是“如何工作”的。最近我一直在研究React Native，我和“事件处理”的斗争过程提醒我了了解_巧合_是多么的重要。因此，我决心收集尽可能多的有关React事件处理的信息：以下是我在[源代码]（github.com/facebook/re… 中找到相关信息的总结报告。
让我们开始React事件之旅吧！
关于React事件处理：概况
从概念的角度说，React中的事件处理并不是什么技术革命，它的目标就是拦截各种事件(比如点击、触摸...)，然后触发程序员编辑的相关回调函数。这种_处理方式_使得React的事件处理方式脱颖而出。
React事件处理流程图
React强调的一点是和谐统一：跨浏览器的React web，跨平台的React Native。但事件系统通过为_React web 和 React Native_创建（几乎）一样的事件处理系统，通过这种方式将这一概念向前推进了一步。 这种想法应该是正确的：同时使用DOM和Native事件——减去一点预处理 ——使用_完全相同的代码_。 React如何揭开这个魔术之谜的呢？这可能是一篇文章的主题（可能写成系列，也有可能这有这么一篇），所以先让我们试着简要的说说。
欢迎来到Fiber的魔法世界
当一个APP更新的时候会发生什么(就是点击更新按钮之后)？新的信息被传播，应用程序被重新渲染。当前，React（web或者native）的核心思想是将上述过程分为两个阶段：“调和”—— React将计算两次文件的不同并决定那一部分需要更新；“渲染”——确定需要更新的位置并更新。看问题的关键在哪？对调和的阶段不关心如何、在哪渲染，只是关注什么需要被渲染。因此，这一阶段可以看作是React Native和React web共同流程。剩下的唯一任务就是插入适当的渲染引擎了。 事件处理是“调和”阶段的一部分，因此发生在同一抽象世界中，在那里浏览器事件和DOM组件与Native事件和组件没有区别。那个世界应该是什么样子的呢？因为我们习惯用有形的可见的事物去类比思考，所以用图片描述它可能有些复杂，但是我们可以明确的是在那个平行宇宙，每一个组件都可以看作是Fiber。确实，React的调和算法不关心组件是如何被渲染的，仅仅关心两次渲染之间的差别，组件本身是不重要的。只有当组件先前的状态和新状态之间存在变化它才会起作用(如果没有变化，自然不起作用)。这就是Fiber：它不是物理实体只是个工作单位，是调和过程中的一小步。
对于那些被上文介绍的Fiber吸引的读者，我建议可以去深入的了解Fiber和React Fiber。这些视频( 作者：Lin Clark )也许是个不错的开始。如果你不是很能理解Fiber的概念也不要担心，这并不是必须的，文章的剩余部分也没有以它为中心将讲开去，只需了解Fiber的交换是个新概念，事件管理系统并没有在此经历任何重大的变化。需要记住的是，React工作在“抽象的世界”，在那里更新独立于组件的物理表示形式而进行：复杂的现实世界中（浏览器，你的手机...），组件被渲染的位置仅是那个唯一的独立设备的宇宙的投影。事务处理没有什么特别的，几乎所有的事都发生在那“抽象的世界”，纠结于事件是来着DOM的还是Native的，似乎并不重要。
在事件处理中，“监听、规范化和再发射”阶段的存在恰恰是为了将真实事件和组件转化为抽象对象。 它捕获来自组件的Native事件，并将它们转换为React中被称为topLevelType与Fiber相关联的东西。 因此，Native事件和组件本身对下游事件处理系统是不可见的，并且没有处理程序安装在“真实”环境中：所有事件都发生在虚拟DOM中。
接收（监听）事件
通过上图我们可以知道，任何情况下，事件的处理都是从监听阶段开始。这并不难理解，毕竟很多人在编程过程中都习惯自定义监听器，比如只对click而不是mousescroll作出反应。但为什么React本身需要监听所有事件呢？ 其实这是因为事件出现在他们的“自然”环境中：用于Web应用程序的DOM，以及移动设备上的Native应用程序。无论是网络还是Native，React都是在这些基本环境的基础上建立的工具。 因此，事件不会主动地返回给React，而是需要React主动监听。
接收事件：React web
对于React web而言，这个过程比较简单，即top-level delegation。 这意味着React监听document级别的每个事件，这还有一个有趣的事儿：到执行任何与React相关的代码时，这个事件已经经过了DOM树上的第一个捕获/冒泡循环。 当从浏览器接收到该事件后，React将执行另一个跨浏览器协调步骤。 作为针对实际上是同一事件的不同名称的浏览器的解决方法，React定义了“topLevelTypes”，作为实际是同一事件但浏览器有给予不同命名的解决办法。它们是针对浏览器特定事件的包装，例如，transitionEnd，webkitTransitionEnd，MozTransitionEnd和oTransitionEnd全都成为topAnimationEnd ，这种方法有效缓解了设计跨浏览器应用程序的痛苦。
接收事件: React Native
对于React Native而言，事件通过Native代码和React相连接的网桥进行接收。 简单的说，无论何时创建View，React都会将其ID号传递给Native，以便能够接收与该元素相关的所有事件。 然后，在向下传递（touch）事件之前执行一些轻微修改，包括将“touches”和“changedTouches”添加到事件以使其符合W3标准 。
从现在开始，为了与之后要介绍的SyntheticEvents相区分开，我们将上文提到的事件”（即来自Native或浏览器，被轻微修改的事件对象）称为 “Native事件”。
React事件管理系统内部一览
现在我们的Native活动，可以跨平台和浏览器进行协调。完美！接下来我们开始准备真正的工作：将这些事件传递给适当的回调函数。React事件系统的真正职责。让我们仔细看看：
React事件系统中的事件流
到处都是事件，尽管如此， EventPluginHub及其事件插件还是非常出色。 EventPluginHub实际上是整个系统的基石，因为它：
- 为事件插件注入提供统一的接口。
- 每接收到一个新的Native事件时，都会通过注入的插件运行，在调度之前返回
SyntheticEvents。
另一方面，事件插件都具有相似的结构，将Native事件作为输入，输出一个或多个SyntheticEvents，并在后面执行一系列调度（函数）。 SyntheticEvent是React对Native事件的特定包装，基本上和大家已经习惯的浏览器事件具有相同的接口，包括stopPropagation（）和preventDefault（）（官方文档事件有一个专门的页面可以提供更多的信息点击这儿)
事件插件
尽管有各种不同的事件插件，如SimpleEventPlugin（onClick，onTouch等等）和非常有名的ResponderEventPlugin，它们都遵循相同的模式：
- 根据Native事件创建一个或多个
SyntheticEvent。. - 收集与
SyntheticEvent（例如onTouchStart = {doStuff}中的doStuff）相关的所有调度（即你提供的函数，编码器）。 - 将每个“SyntheticEvent”与其调度一起返回。
值得注意的是实际上没有调度任何插件，因为它只收集自己的函数。（大多数时候，也就是说，一些插件在收集阶段执行一些特定的调度，但这是例外情况而并非常态）。SyntheticEvent可以简单地镜像Native事件（比如click或drag），或者更复杂一些（比如touchTap），但是在所有情况下它们都会返回调度数组，以便“准备处理“。
为了收集调度，React对组件进行双重遍历（无论是Native的还是DOM），具有从根到嵌套目标（捕获阶段）回到根（冒泡阶段）的捕获和冒泡阶段。
双遍历
请注意，对于所有不同的调度（在插件本身之外执行的调度，即大部分调度），双遍历普遍会发生。诸如stopPropagation（）之类的中断将在调度中生效，从而有效地阻止了此SyntheticEvent的后续函数的执行（参见结论）。
关于EventPluginHub
当应用程序启动时，所有事件插件都被注入到EventPluginHub中，并且按照配置文件对其排序。在运行工程中，每一次接收到Native事件时，EventPluginHub都将执行以下操作：
- 对于每个插件（按顺序），收集所有
SyntheticEvents及其调度配置并将它们存储在队列中。 - 对队列中的所有事件执行相应的调度，并将其从队列中清除。
就是这样！ 你的回调函数就是通过这种方式进行工作的。:)
总结 & 结论
An interesting consequence of this system is that a single native event can (and will, most of the time) generate multiple **SyntheticEvent**s, each with a scope limited to the plugin that created it. This means that: 有趣的是在这个系统中一个native事件可以(大多数情况下)生成多个 **SyntheticEvent**每一个的工作范围在创建它的组件里。这意味着：
- 只有
SyntheticEvent中的nativeEvent部分将从插件传递给插件，所以对nativeEvent的修改可能会影响后续插件的执行，但对SyntheticEvent的修改则不能。 - 由于
SyntheticEvent的范围有限，所以stopPropagation（）等调用方法仅适用于单一事件插件。
为第二点举个例子，假设我们有两个插件A和B，分别定义了合成事件eventA和eventB。假设这些事件在冒泡阶段被称为onEventA和onEventB，在捕获阶段被称为onEventACapture和onEventBCapture。最后，两者都由相同的topLevelType（例如topClick）触发，命令为[A, B]。现在考虑React Native中的以下代码（只需将View替换为React web的div）：
-- -------------------- ---- -------
----- --- ------- --------------- -
-------- -
-------
-----
--------------- -- ------------------------
--------------- -- -------------------------
-----
---------------------- -- ----------------------
--
-------
-
-
-
任何点击事件都会先触发eventA的捕获阶段，在嵌套组件中调用stopPropagation（）将有效地防止后续冒泡阶段。因此，'onEventA'不会出现。 但是，由于eventB已经被定义在不同的插件中，因此依赖于不同的SyntheticEvent，所以**'onEventB'**将会在控制台输出。 虽然这是一个相当极端的情况，但我们导致意外情况发生的时机。
关于React的事件处理系统还有很多的话要说，比如SyntheticEvents ，为了避免矫枉过正我就不在这儿提及了。
通过阅读源码(可惜关于这个主题没有太多深入的文档)和观看视频(作者：Kent C. Dodds, Dan Abramov)，希望你也可以和我一样有所收获！
接下来，我将继续深入地学习，看看引擎下的东西是如何运行的。
来源：JavaScript中文网 ，转载请注明来源 https://www.javascriptcn.com/post/30127