事件捕获是必要/首选的真实世界示例？ [英] Real world example where event capturing is necessary / preferred?

查看：131 发布时间：2019/6/7 22:05:10 javascript requirements dom-events event-propagation event-capturing

本文介绍了事件捕获是必要/首选的真实世界示例？的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

addEventListener DOM方法支持第三个可选的布尔参数（useCapture）来指示该函数是否应该使用事件冒泡或事件捕获作为传播方法。在这篇文章中，很好地展示了差异（点击示例和查看代码）。

The addEventListener DOM method supports a third optional, boolean parameter (useCapture) to indicate whether the function should use event bubbling or event capturing as propagation method. In this article the difference is nicely shown (click on the examples & view code).

从SO和博客文章的其他问题来看，我认为事件冒泡主要是因为IE8-不支持它。

From other questions on SO and blog posts, I concluded event bubbling was preferred mostly because IE8- didn't support it.

假设我只需要支持IE9 +，在什么情况下事件捕获对于事件冒泡是必要的还是首选的？换句话说，在什么情况下最好让事件首先在最外面的元素上执行，然后在最里面的元素上执行？我正在寻找一个简单的，真实世界的例子来演示事件捕获的使用......

Suppose I'm only required to support IE9+, in what situation would event capturing be necessary or preferred over event bubbling? In other words, in what situation would it be better to let the events execute on the outermost elements first, and then the innermost elements? I'm looking for a simple, real world example to demonstrate the use of event capturing...

推荐答案

事件捕获用于是Internet Explorer浏览器之外的唯一选择：

Event capturing used to be the only option outside of the Internet Explorer browser:

当时两个重要浏览器的主要区别之一是它们如何处理事件。 Microsoft使用冒泡阶段 - 意味着事件首先传递父元素，然后向下运行到目标元素。 Netscape以其他方式完成它 - 并且事件首先命中目标元素，然后遍历整个DOM向上命中父节点 - 捕获。这导致开发人员在早期遇到很多麻烦，而W3C最终指定了一种方法，两种方式都可以免费使用。

One of the major differences of the back then two important browsers was how they handled events. Microsoft worked with the bubbling phase - meaning the event first passes the parent elements and then runs down to the target element. Netscape did it the exact other way - and had the event first hit on the target element and then traverse the whole DOM upwards hitting on the parent nodes - capturing. This caused developers in the early days a lot of trouble and the W3C finally specified an approach where both kind of works and can be used at free will.

当不支持冒泡时，事件捕获在事件委派中很有用。例如：

Event capturing is useful in event delegation when bubbling is not supported. For example:

某些事件（例如焦点）不会冒泡但可以捕获。
目标元素的内联处理程序在目标元素的捕获处理程序之前触发。

Some events, such as focus, don't bubble but can be captured. The inline handler on the target element triggers before capture handlers for the target element.

Web平台中的许多新指定事件（例如媒体事件）不要冒泡，这对依赖事件委托的Ember这样的框架来说是一个问题。但是，在IE9中添加的捕获API可以针对所有事件正确调用，并且不需要规范化层。支持捕获API不仅允许我们删除jQuery依赖项，而且它将允许我们正确处理这些非冒泡事件。这将允许您使用诸如在组件中播放之类的事件而无需手动设置事件侦听器。

Many newly specified events in the web platform (such as the media events) do not bubble, which is a problem for frameworks like Ember that rely on event delegation. However, the capture API, which was added in IE9, is invoked properly for all events, and does not require a normalization layer. Not only would supporting the capture API allow us to drop the jQuery dependency, but it would allow us to properly handle these non-bubbling events. This would allow you to use events like playing in your components without having to manually set up event listeners.

自定义事件和冒泡具有以下问题：

Custom events and bubbling have the following issues:

目前，Ember依赖jQuery进行事件处理，这样做会带来几个成本：

Currently, Ember relies on jQuery for event handling, doing so comes with several costs:

jQuery silently changes inline handlers to bubble handlers.
    This changes expected invocation order
    This can cause automated tests to fail
Events triggered via jQuery.trigger trigger handlers in a different order than events triggered by a user.
    This changes expected invocation order
    This leads to difficult to reason about and debug aberrations in behavior
    This often causes automated tests to fail
Events must flow down and bubble back up through the entire DOM before being detected by the Ember application, and then must undergo an expensive delegation process that is effectively re-bubbling to find the right handler.
Handlers attached directly within components or by non-ember plugins take precedent over handlers attached by Ember, whether this was desired or not.

    This causes component handlers to have far-reaching side-effects
    This leads to difficult to reason about and debug aberrations in behavior
    This often causes automated tests to fail

媒体播放器焦点=>播放预处理/后处理事件流将是一个简单的用例。

A media player focus=>play preprocess/postprocess event flow would be a simple use case.

捕获阶段的机制使其成为准备或防止随后在冒泡阶段由事件委派应用的行为的理想选择。这就是我们在这里使用它的方法 - 初始化可点击以响应鼠标点击，但就在事件开始冒泡之前，其他处理程序有机会处理它。

The mechanics of the capturing phase make it ideal for preparing or preventing behavior that will later be applied by event delegation during the bubbling phase. And that’s how we’re going to use it here—to initialize the sortable in response to a mouse click, but just before the event starts bubbling and other handlers have a chance to deal with it.

为了利用捕获，我们必须采用金属。 jQuery的事件方法只适用于冒泡，不要让我们进入捕获阶段。捕获处理程序如下所示：

To make use of capturing, we have to go down to the metal. jQuery’s event methods only work for bubbling and don’t let us tap into the capturing phase. The capturing handler looks like:

    document.addEventListener("mousedown", function(event) {
      if ($(event.target).closest(".sortable_handle").length) {
         $("article.todolist, section.todolists").sortable();
         }
      }, true);

参考