Пример из реальной жизни, где необходима/предпочтительна запись событий?

Метод addEventListener DOM поддерживает третий необязательный логический параметр (useCapture), указывающий, должна ли функция использовать в качестве метода распространения событие пузырьковое или событие захват. В этой статье хорошо показана разница (нажмите на примеры и просмотрите код).

Из других вопросов о SO и сообщениях в блогах я пришел к выводу, что всплытие событий предпочтительнее в основном потому, что IE8- не поддерживает его.

Предположим, что от меня требуется только поддержка IE9+. В какой ситуации захват событий будет необходим или предпочтительнее всплытия событий? Другими словами, в какой ситуации было бы лучше позволить событиям сначала выполняться на самых внешних элементах, а затем на самых внутренних элементах? Я ищу простой пример из реальной жизни, чтобы продемонстрировать использование захвата событий...


javascript dom-events event-propagation requirements event-capturing
person Tyblitz    schedule 16.07.2014    source источник
comment
Из статьи, которую вы связали In real-life the capturing phase is rarely used. But.. There are events which don’t bubble, but can be captured. For example, onfocus/onblur.   -  person Huangism    schedule 16.07.2014
comment
@Huangism Это все хорошо и хорошо, но я все же хотел бы увидеть более конкретный пример, где это было бы полезно, например. в мини-приложении или функции, которые более или менее требуют или лучше используют захват событий вместо всплывающих сообщений   -  person Tyblitz    schedule 16.07.2014
comment
stackoverflow.com/a/11711071/2545680   -  person Max Koretskyi    schedule 26.11.2016
comment
поработайте немного с D3, и вы скоро найдете пример. очень редко там, где он нужен, но может случиться так, что он понадобится вам хотя бы раз в жизни :) наверное не более 3-х раз.   -  person vsync    schedule 26.11.2016

Ответы (1)


arrow_upward
4
arrow_downward

Захват событий раньше был единственным вариантом за пределами браузера Internet Explorer:

Одним из основных различий между двумя важными браузерами того времени было то, как они обрабатывали события. Microsoft работала с фазой всплытия — это означает, что событие сначала попадает в целевой элемент, а затем проходит через весь DOM вверх, попадая в родительские узлы, тогда как Netscape делал это совершенно другим способом — это означает, что событие сначала проходит через родительские элементы, а затем спускается к целевой элемент - захват. Поначалу это доставляло разработчикам много неприятностей, и W3C, наконец, определил подход, при котором оба типа работают и могут использоваться по доброй воле.

Захват событий полезен при делегировании событий, когда всплывающее представление не поддерживается. Например:

Некоторые события, такие как фокус, не всплывают, но могут быть захвачены. Встроенный обработчик целевого элемента срабатывает перед обработчиками захвата целевого элемента.

Многие новые определенные события в веб-платформе (например, медиа-события) не всплывают, что является проблемой для таких фреймворков, как Ember, которые полагаются на делегирование событий. Однако API захвата, добавленный в IE9, правильно вызывается для всех событий и не требует слоя нормализации. Поддержка API захвата не только позволила бы нам отказаться от зависимости jQuery, но и позволила бы нам правильно обрабатывать эти не всплывающие события. Это позволит вам использовать такие события, как воспроизведение, в ваших компонентах без необходимости вручную настраивать прослушиватели событий.

Настраиваемые события и всплывающая подсказка имеют следующие проблемы:

В настоящее время Ember полагается на jQuery для обработки событий, что требует нескольких затрат:

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

Простым вариантом использования будет поток событий focus=›play медиаплеера preprocess/postprocess.

Механика фазы захвата делает ее идеальной для подготовки или предотвращения поведения, которое позже будет применено делегированием событий на этапе всплытия. И именно так мы собираемся использовать его здесь — для инициализации сортируемого объекта в ответ на щелчок мыши, но непосредственно перед тем, как событие начнет всплывать, и другие обработчики смогут с ним справиться.

Чтобы использовать захват, мы должны спуститься к металлу. Методы событий jQuery работают только для всплытия и не позволяют нам подключиться к фазе захвата. Обработчик захвата выглядит так:

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

Ссылки

person Paul Sweatte    schedule 26.11.2016