前言: 此篇文章稍长,请您用心阅读,完后我相信会解决你许多疑惑。
我们以一个 toy demo 开始.
// dom level
-> div (onclick)
-> p
-> span
问题 : 为什么当我们点击<p&
gt;, <span&
gt; click 事件也触发了?
Bubbling(冒泡)
冒泡是事件的一种传递机制,当一个事件发生时,事件会以相反的顺序传播通过目标再父级祖先,最后以 Window 结束。
就拿之前的例子 来说,当用户点击<span&
gt;元素时,事件会从下至上(子元素->祖先)依次触发 click 事件。并且几乎所有的事件都会有冒泡阶段。
Capture (捕获)
我们知道在事件的传递机制中除了冒泡还有一种我们经常提到的就是捕获机制。
其实这是不完全正确的!!!,依据W3C 的定义, 事件的传递分为了3 阶段:
- Capture(捕获阶段): 事件对象通过 Window 传播到目标的祖先父级再到自身。
- Target(目标阶段): 事件对象到达目标自身, 当该事件类型指定不 Bubble, 则事件将在此阶段终止(稍后解释)。
- Bubble(冒泡阶段): 事件对象以相反的顺序传播通过目标的父级祖先,并以 Window 结束。
![v2-745d8536743226a910274a5af3b32746_b.jpg](http://img-01.proxy.5ce.com/view/image?&type=2&guid=f829d0e3-0e30-eb11-8da9-e4434bdf6706&url=https://pic3.zhimg.com/v2-745d8536743226a910274a5af3b32746_b.jpg)
所以当一个事件发生时标准的传递流为 捕获 -> 目标 -> 冒泡
当我们程序在主流的浏览器运行时,我们在 html 中使用 on[eventType]
或者 javascript 中使用 element. addEventListener(eventType, listener)
这些 Web API 像是忽略了 捕获阶段 只会运行 目标阶段 和 冒泡阶段。
问题 :那么这时候就产生了一个问题? 若我们在一个嵌套的 Dom 上分别添加事件,我们就不能改变事件的触发顺序(子元素绑定的事件会先于父元素绑定的事件触发),我们如何改变这个顺序?
EventListener Option -【 options ={}
| useCapture = boolean 】
感谢 Web API 的完备性,如果你看过 addEventListener
API 的定义,你会发现,声明是有第三个参数选项的,它可传入一个 boolean 或者 一个对象。
elem.addEventListener(type, listener[, options]);
elem.addEventListener(type, listener[, useCapture]);
所以当你在一个 元素 上添加对应的事件监听时, 你可以这样写:
elem.addEventListener(_, _, { capture: true });
// 对象的形式还接受更多的option:[once,...]
// 或者
elem.addEventListener(_, _, true);
他们是等价的,表示监听的回调将会在 捕获阶段 被触发。那么这样我们可以解决上面的问题。 例如:
// dom level
-> div (onclick= log('div', true))
-> p (onclick = log('p'))
-> span
// 此时输出顺序为 div -> p
// 相反
-> div (onclick= log('div'))
-> p (onclick = log('p'))
-> span
// 此时输出顺序为 p -> div
listener callback param - Event
首先对于 listener 来说,它不仅仅只能传入function
还能是一个对象但这个对象必须实现Event
接口(包含handleEvent(fn)
属性),在此我们不对它过多解释,具体可以去参看文档.
接下来我们具体说说 listener 被调用时传入的参数 Event 或 简写为 e
e.target
// dom level
-> div (onclick)
-> p
-> span
还是使用之前的例子,我们解释几个误区(这里可能存在错误 ,希望大佬发现后不吝纠正):
⚠️ 误区 1 : 当<div>
添加了 click 事件,是否代表 <p>
, <span>
也添加了 click 事件
答: ❌, 事实上在 <div>
添加了 click 与它的子元素并没有任何关系,但是可以通过 Event
对象拿到触发事件的真正对象,这看起来就好像是 <div>
的子元素同样添加了此事件监听。记住回调是发生在添加事件监听的目标元素身上的(click 的 listener callback 是发生在 div
上的)。
⚠️ 误区 2: 既然事件的传递分为 捕获 -> 目标 -> 冒泡,那么为什么一次点击事件不会多次触发。
答: 从之前的 addEventListener API 我们知道 事件是可以绑定到 冒泡 或者 捕获 阶段的,当没有设置时默认是在 冒泡阶段 所以只会触发一次,那就是在对应绑定的阶段。
注意: 既然添加事件是区分阶段,那么在移除此事件时也需要明确对应阶段。
解释了上述误区,我们回过来说 e.target
: 当事件触发时,e.target
(read-only)的值为最深嵌套相关元素,并不一定为添加事件所对应元素。例如上诉例子,当你点击<span>
时事件传递冒泡走到<div>
元素其 click 事件回调被触发,而e.target
的值是 span
元素对象。
e.currentTarget
我们知道了 e.target
(read-only) 并不一定为添加事件所对应元素,那么如何在回调中知道是那个元素添加的此事件监听呢? 这就是 e.currentTarget
,另外在 listener 方法内部也可以直接使用 this
,它等同于(this = event.currentTarget
)
e.path
e.path
(read-only)为一个数组eg: [span, p, div, body, html, document, Window]
它表示从 e.target
到 window
所经历到元素层级。
e.stopPropagation()
我们在事件传递阶段讲 捕获阶段 的时候提到 可以提前终止不在进行冒泡阶段。 这是怎么做的了,其实可以在捕获阶段添加的监听事件回调被调用时候调用e.stopPropagation()
来阻止事件在 DOM 中进一步传播。 由于历史原因也可以调用 e.cancelBubble = true
来阻止事件冒泡(但不建议使用此属性,最好使用 stopPropagation
方法)
e.[other]
Event
对象上还有许多属性,在这里不会全部罗列,最常用的基本上就是以上几个,其余属性还可以拿到很多信息,但部分属性可能并不是标准
以上是有关 EventListener 一些常识,希望大家能够不吝赐教
如果还有未涉及到的,欢迎提出讨论。
Why write this ?
略...