为了账号安全,请及时绑定邮箱和手机立即绑定

React和React Native事件系统详解:和谐共存

2018.04.22 18:59 696浏览

使用它,喜欢它,但是你真的了解它吗?知道React事件如何在底层处理实现吗?

已经有很多帖子解释了如何使用React的事件处理系统,但是并没有多少帖子是在解释他们是“如何工作”的。最近我一直在研究React Native,我和“事件处理”的斗争过程提醒我了了解_巧合_是多么的重要。因此,我决心收集尽可能多的有关React事件处理的信息:以下是我在[源代码](https://github.com/facebook/react)中找到相关信息的总结报告。

让我们开始React事件之旅吧!

关于React事件处理:概况

从概念的角度说,React中的事件处理并不是什么技术革命,它的目标就是拦截各种事件(比如点击、触摸...),然后触发程序员编辑的相关回调函数。这种处理方式使得React的事件处理方式脱颖而出。

https://img4.mukewang.com/5adc6b270001712120001493.jpgReact事件处理流程图

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中被称为topLevelTypeFiber相关联的东西。 因此,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”,作为实际是同一事件但浏览器有给予不同命名的解决办法。它们是针对浏览器特定事件的包装,例如,transitionEndwebkitTransitionEndMozTransitionEndoTransitionEnd全都成为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()(官方文档事件有一个专门的页面可以提供更多的信息点击这儿)

事件插件

尽管有各种不同的事件插件,如SimpleEventPluginonClickonTouch等等)和非常有名的ResponderEventPlugin,它们都遵循相同的模式:

  1. 根据Native事件创建一个或多个SyntheticEvent。.

  2. 收集与SyntheticEvent(例如onTouchStart = {doStuff}中的doStuff)相关的所有调度(即你提供的函数,编码器)。

  3. 将每个“SyntheticEvent”与其调度一起返回。

值得注意的是实际上没有调度任何插件,因为它只收集自己的函数。(大多数时候,也就是说,一些插件在收集阶段执行一些特定的调度,但这是例外情况而并非常态)。SyntheticEvent可以简单地镜像Native事件(比如clickdrag),或者更复杂一些(比如touchTap),但是在所有情况下它们都会返回调度数组,以便“准备处理“。

为了收集调度,React对组件进行双重遍历(无论是Native的还是DOM),具有从根到嵌套目标(捕获阶段)回到根(冒泡阶段)的捕获和冒泡阶段。

双遍历

请注意,对于所有不同的调度(在插件本身之外执行的调度,即大部分调度),双遍历普遍会发生。诸如stopPropagation()之类的中断将在调度中生效,从而有效地阻止了此SyntheticEvent的后续函数的执行(参见结论)。

关于EventPluginHub

当应用程序启动时,所有事件插件都被注入到EventPluginHub中,并且按照配置文件对其排序。在运行工程中,每一次接收到Native事件时,EventPluginHub都将执行以下操作:

  1. 对于每个插件(按顺序),收集所有SyntheticEvents及其调度配置并将它们存储在队列中。

  2. 对队列中的所有事件执行相应的调度,并将其从队列中清除。

就是这样! 你的回调函数就是通过这种方式进行工作的。:)

总结 & 结论

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()等调用方法仅适用于单一事件插件。

为第二点举个例子,假设我们有两个插件AB,分别定义了合成事件eventAeventB。假设这些事件在冒泡阶段被称为onEventAonEventB,在捕获阶段被称为onEventACaptureonEventBCapture。最后,两者都由相同的topLevelType(例如topClick)触发,命令为[A, B]。现在考虑React Native中的以下代码(只需将View替换为React web的div):

class App extends React.Component {
  render() {    return(
      <View
        onEventA={(evt) => console.log('onEventA')}
        onEventB={(evt) => console.log('onEventB')}>
        <View
          onEventACapture={(evt) => evt.stopPropagation()}
        />
      </View>
    )
  }
}

任何点击事件都会先触发eventA的捕获阶段,在嵌套组件中调用stopPropagation()将有效地防止后续冒泡阶段。因此,'onEventA'不会出现。 但是,由于eventB已经被定义在不同的插件中,因此依赖于不同的SyntheticEvent,所以**'onEventB'**将会在控制台输出。 虽然这是一个相当极端的情况,但我们导致意外情况发生的时机。


关于React的事件处理系统还有很多的话要说,比如SyntheticEvents ,为了避免矫枉过正我就不在这儿提及了。

通过阅读源码(可惜关于这个主题没有太多深入的文档)和观看视频(作者:Kent C. Dodds, Dan Abramov),希望你也可以和我一样有所收获!

接下来,我将继续深入地学习,看看引擎下的东西是如何运行的。

译文出处

点击查看更多内容
0人点赞

若觉得本文不错,就分享一下吧!

评论

相关文章推荐

正在加载中
意见反馈 去赚学费 帮助中心 APP下载
官方微信

举报

0/150
提交
取消