Захват событий против событий

Question

Я просто хотел получить общее согласие относительно лучшего способа делегирования событий в JS между всплытием и захватом.

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

Или, другими словами, есть ли причина для реализации W3C addEventListener в пользу режима пузыривания? [захват начинается только тогда, когда вы указываете третий параметр и его значение true. Тем не менее, вы можете забыть, что 3-й параметр и режим всплытия включаются]

Я посмотрел функцию привязки JQuery, чтобы получить ответ на мой вопрос, и кажется, что он даже не поддерживает события в фазе захвата (мне кажется, потому что IE не поддерживает режим захвата).

Похоже, режим пузырьков является выбором по умолчанию, но почему?

Answer 1

В прошлом это была проблема с платформой, в Internet Explorer была пузырьковая модель, а Netscape больше занимался захватом (но поддерживал оба варианта).

Модель W3C требует от вас выбора, какой вы хотите.

Я думаю, что пузырьки более популярны, потому что, как уже говорилось, есть некоторые платформы, которые поддерживают только пузырьки ... и , это своего рода имеет смысл как режим по умолчанию.

Какой из них вы выбираете, в значительной степени является результатом того, что вы делаете, и что имеет для вас смысл.

Answer 2

Читая JavaScript: «Полное руководство», 5-е издание, я натолкнулся на пример 17-4 на странице 422, который определяет функцию для перетаскивания абсолютно позиционированных элементов. В этом примере функция drag() вызывается в атрибуте onmousedown элемента документа. Функция перемещает элемент на основе изменения местоположения мыши, которое запрашивается обработчиками, добавленными к корневому элементу документа для захваченных событий mousemove и mouseup. Они фиксируют эти события в документе по следующей причине:

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

Это дает преимущество в более быстром отклике при захвате событий.

Answer 3

Этот тест предполагает, что есть небольшое преимущество в производительности при использовании захвата над пузырем. Даже не убивая событие, как только оно будет обработано, однако, когда оно было оставлено, оно было маргинальным. Я полагаю, сложный DOM преувеличил бы разницу в производительности между ними.

Answer 4

Эта ссылка дает четкое объяснение - https://www.quirksmode.org/js/events_order.html

Вы, веб-разработчик, можете выбрать, регистрировать ли обработчик событий в процессе захвата или в фазе всплытия. Это делается с помощью метода addEventListener(), описанного на странице Расширенные модели. Если его последний аргумент равен true, обработчик событий установлен для фазы захвата, если он равен false, обработчик событий установлен для фазы пузырьков.

Предположим, вы делаете

element1.addEventListener('click',doSomething2,true)
element2.addEventListener('click',doSomething,false)

Если пользователь нажимает на элемент 2, происходит следующее:

Событие щелчка начинается на этапе захвата. Событие проверяет, есть ли у какого-либо предка элемента element2 обработчик события onclick для фазы захвата. Событие находит один на element1. doSomething2 () выполняется. Событие перемещается вниз к самой цели, больше не найдено обработчиков событий для фазы захвата. Событие переходит в фазу пузырьков и выполняет doSomething (), которая зарегистрирована в element2 для фазы пузырьков. Событие снова движется вверх и проверяет, есть ли у какого-либо предка элемента цели обработчик события для фазы пузырьков. Это не так, поэтому ничего не происходит. Обратное будет

element1.addEventListener('click',doSomething2,false)
element2.addEventListener('click',doSomething,false)

Теперь, если пользователь нажимает на элемент 2, происходит следующее:

Событие щелчка начинается на этапе захвата. Событие ищет, имеет ли какой-либо элемент-предок element2 обработчик события onclick для фазы захвата, и не находит его. Событие движется вниз к самой цели. Событие переходит в фазу пузырьков и выполняет doSomething (), которая зарегистрирована в element2 для фазы пузырьков. Событие снова движется вверх и проверяет, есть ли у какого-либо предка элемента цели обработчик события для фазы пузырьков. Событие находит один на element1. Теперь doSomething2 () выполняется. Совместимость с традиционной моделью В браузерах, которые поддерживают W3C DOM, традиционная регистрация событий

element1.onclick = doSomething2;

рассматривается как регистрация в фазе барботирования.

Использование всплытия событий Немногие веб-разработчики сознательно используют захват событий или всплытие. В веб-страницах, как они сделаны сегодня, просто нет необходимости допускать, чтобы пузырьковое событие обрабатывалось несколькими различными обработчиками событий. Пользователи могут запутаться в нескольких вещах, происходящих после одного щелчка мышью, и обычно вы хотите разделить свои сценарии обработки событий. Когда пользователь нажимает на элемент, что-то происходит, когда он нажимает на другой элемент, что-то еще происходит.

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

Answer 5

Я не уверен, но я уверен, что все, что вы можете сделать с пузырьками, вы можете сделать с захватом и наоборот.

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

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