Страницы

Поиск по вопросам

суббота, 11 января 2020 г.

Обработка событий

#javascript #html


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

Хотелось бы узнать как производительнее и легче браузеру? Или хотя бы как можно это
правильно протестировать? 

Давайте считать, что у нас на странице много (100-500) обработчиков и сама страница
это лес из div'ов. Мне кажется, за счет того, что между самим событием и его всплытием
до window происходит некоторое время + время расходуется на выбор правильного делегата.
Это может влиять на производительность. Помогите разобраться или это я бешусь с жиру
и всё равно как делать на самом деле.
    


Ответы

Ответ 1



Браузеру производительней обрабатывать события на месте. Имхо не так много причин за вешать обработчик на window, зато куча против. Событию нужно всплыть до window, его могут перехватить и отменить Обработчики будут возбуждаться на все события данного типа и проверять не возникло ли оно на нужном элементе и нужно ли его обработать Обработка будет откладываться пока событие всплывает и обрабатывается более конкретными обработчиками Нельзя будет выстроить порядок обработки повесив дополнительные обработчики на родительский элемент чтобы они выполнились после

Ответ 2



Первое к чему должен стремится каждый человек, это позаботится чтобы его дело приносило только удовольствие. Если Вы будите писать обработчики на window, то Вам придется вести собственный реестр чтобы событие дошло таки до получателя и скорее всего элементам придется давать уникальные id. И мне кажется что если Вы не пишите какой-то фраймворк, то данная затея будет неоправданна. Ведь согласитесь, в реальности не бывает таких вложенностей чтобы заметить разницу производительности на пару кликах. И если тест проведенной под запредельно высокой нагрузкой, которую в жизни не может существовать, покажет существенную разницу, то это может натолкнуть на негативные мысли склоняющие к оптимизации событий. А в реальности события не являются предметом оптимизации, если это не mousemove, scroll или что-то связанное с requestAnimationFrame. Да и то оптимизация сводится к созданию единой точки распространения (создание сервиса, менеджера) и создана лишь для того чтобы минимизировать обращение к dom элементам, работа с которыми является наиболее узким местом при оптимизации приложения.

Комментариев нет:

Отправить комментарий