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

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

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

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

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

Так выглядит, как режим барботирования является выбором по умолчанию, но почему?

Ответ 1

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

Модель W3C требует, чтобы вы могли выбрать, какой из них вы хотите.

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

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

Ответ 2

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

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

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

Ответ 3

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

Ответ 4

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

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

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