01期：web浏览器事件传播机制（捕获和冒泡）

最新推荐文章于 2023-04-23 23:30:18 发布

cai649399010

最新推荐文章于 2023-04-23 23:30:18 发布

阅读量1.1k

点赞数 1

分类专栏： IT一大道至简文章标签：事件传播机制冒泡web

本文链接：https://blog.csdn.net/cai649399010/article/details/76099943

版权

IT一大道至简专栏收录该内容

4 篇文章 0 订阅

订阅专栏

今天想跟大家分享一下我对web事件传播机制的理解。

一、背景

在实际开发过程中，我们有时会给多个具有嵌套关系的dom元素，绑定类型相同但处理不同的event listener，如click listener。当内层元素绑定的click事件被触发时，其外层元素的click事件也会被触发，那么请思考一下，如何控制它们的执行顺序？

二、web标准定义的listener执行顺序

在确定执行顺序之前，我们先看一下存在哪几种可能的执行顺序。从dom元素的嵌套关系来看:

我们可以看到两种基本顺序，一是从“外到内”，二是“从内到外”。而web标准采用的顺序是“先从外到内，再从内到外”，是这两种基本顺序的拼接。刚好是一个来回、一个往返，我喜欢把这种顺序定义为“公交路线”。

特别地，

1. 每一个嵌套的dom元素都可以看成是“公交路线”上的一个巴士站，，每一个巴士站都会经停两次，第一次是巴士出站时，第二次是巴士回站时（ps：bus总站为最外层元素，终点站为最内层元素）；

2. 每一个绑定在dom元素的listener可以看作是一个乘客，同一个dom元素可能绑定多个listener，意味着有个乘客队列，遵循“先上车先执行，上车即执行”原则（ps：此原则同样适用于具有嵌套关系的多个dom元素间的listeners）；

三、两种基本顺序的命名

在谈命名前，我先描述一下“陨石坠落到地球及其事件上报”的过程：

打个比喻，太空有一颗巨大的陨石进入地球大气层，经过5小时，到达了中国领空（具体坠落到何处尚不能知晓）；再经过5小时，坠落轨迹已经稳定在广东省境内；再经过5小时，轨迹稳定在深圳市；再经过30分钟，轨迹稳定在南山区；再经过10分钟，陨石最终坠落在桂庙村。桂庙村村委会在查看现场后，立即把事件的详情上报到南山区政府，而南山区政府接着把事件上报给深圳市政府，而深圳市把又接着把事件上报给省级单位......经过一级一级的上报，最后，中央政府也知悉此事件。

这个过程，可细分为有三个过程：

1. 陨石坠落过程(go down)，也是从外到内的过程；

2. 陨石到达地球桂庙村(reach target)；

3. 事件详情逐层上报(bubble up冒泡上升)，也是从内到外的过程。

过程讲完了，我们回到对两种基本顺序命名的问题。通过查阅资料可知，官方把“从外到内”的顺序命名为Capturing，“从内到外”的顺序命名为Bubbling。结合刚描述完的“陨石坠落到地球及其事件上报”过程，将“从内到外”理解为Bubbling问题不大，因为Bubbling正好对应之前提及的bubble up（上报）。而将“从外到内”与Capturing直接联系在一起，就似乎有那么一点困难。

我想你我也有过同样的困惑。而后来我是通过这样来理解：回到我之前的陨石坠落的比喻，在陨石坠落的过程中，我们是无法最终确定其将reach到地表何处，但是我们可以确定的是，陨石先进入地球（先被地球知晓），再进入中国领空（再被中国知晓），后进入深圳领空（后被深圳知晓）......最终到达桂庙村（最终被桂庙村知晓）。

从上述过程可知，“知晓”先始于从外层，终于里层，而欲“捕获”则应先“知晓”，可知“捕获”也是先始于从外层，终于里层。这样就不难理解为何把“从外到内”的顺序命名为Capturing。

四、如何设置事件监听器在哪个基本顺序执行（Capturing or Bubbling）

先看看官方提供的给元素增加事件监听器的接口：

element.addEventListener(type, listener[, useCapture]);

其中的useCapture（使用捕获）参数，就是用于设置当前listener在哪个基本顺序执行：当检测到type事件触发时，useCapture为true，表示会在“公交路线”的“Capturing”方向搭载（执行）当前listener；为false，表示会在“公交路线”的“Bubbling”方向搭载（执行）当前listener。

再来讨论一下useCapture的默认值，可以思考一下为什么是false，而是true？按我的理解，false更符合一般的认知规律：就好比陨石落到地表之后，事件传播的一般顺序是由下级区域上报(bubble up)给上级区域，上级区域是被动知道事件的发生。相应地，外层元素好比上级区域，内层元素好比下级区域，也可以认为在默认情况下，外层元素捕获到的事件也是源于内层元素的上报。不知道这种解释有没有帮助你记忆？

另外，我想补全一下useCapture中的capture语义来帮助理解:The dom element captures the event and does sth in the relevant listener. 在读完之后，我们不难从句子中读到一种主动的蕴味。也就是说，useCapture为true时，表示dom元素是主动捕获事件（而不是被下层元素通知事件）；相对地，为false时，表示dom元素是被动知道事件（由下层元素通知）。因为如之前所说，由下层元素上报而知道事件的发生，更符合一般的事件传播顺序，所以setCapture设为false更具有普遍性，设为默认值也更为合理。

五、事件监听器开始执行的前置条件：事件对象已初始化完毕（target已确定）

我们在网上经常会看到这样的现象（我以前也有这样理解）：就是认为listeners的执行是穿插在浏览器的事件解析、捕获和传播过程（包含事件对象初始化），举例如下：

html结构：

js代码（listener的useCapture均设为true，让其在元素捕获到事件时执行）：

实际结果：

所有的target均指向最里层的触发了事件的dom元素，即target.id均为station4。

其实web标准定义的事件执行顺序，与浏览器的事件解析、捕获和传播过程（包含事件对象初始化），是两个无交叉的过程。二者之间的关系仅仅是官方在给事件基本执行顺序命名的时候，借用了后者的术语Capture和Bubble（把“从外到内”的顺序命名为Capturing，“从内到外”的顺序命名为Bubbling）。而事实上，listeners的执行，是在“事件对象生成并初始化完毕”之后，从上述的“实际结果”可知（详见代码e.target.html）。最后再强调几点：

1. 事件对象的初始化，包括event.target的确定（对应最内层的dom元素）；

2. 在event.target确定之后，事件触发的相关listeners方开始执行；

3. 由同一个用户行为触发执行的listeners, 无论其实是在Capturing方向还是Bubbling方向，其event target均一样。

六、从代码中理解事件传播机制

讲完概念之后，是时候上代码了！