В чем разница между различными способами обработки пользовательских событий в JavaScript?

Question

Я сталкивался с постами ниже о пользовательской обработке событий в JavaScript. Из этих статей есть два (как минимум) способа обработки / запуска пользовательских событий:

1. Использование методов DOM (createEvent, dispatchEvent)
   • Как мне создать собственный класс событий в Javascript?
   • http://the.unwashedmeme.com/blog/2004/10/04/custom-javascript-events/
     
     
2. Пользовательский код
   • http://www.nczonline.net/blog/2010/03/09/custom-events-in-javascript/
   • http://www.geekdaily.net/2008/04/02/javascript-defining-and-using-custom-events/

Но каков рекомендуемый способ обработки (запуска и подписки) пользовательских событий?

[Редактировать] В контексте этого вопроса не используются никакие библиотеки, такие как jQuery, YUI, ..., а просто обычный JavaScript

[Редактировать 2] Кажется, есть небольшие различия, по крайней мере, с обработкой ошибок. Дин Эдвардс (http://dean.edwards.name/weblog/2009/03/callbacks-vs-events/) рекомендует первый способ обработки пользовательских событий. Мож мы сказать, что это разница?

Answer 1

Чем вы описываете разницу между

• Система передачи сообщений на основе пользовательских событий
• запуск событий DOM вручную.

Первый способ использовать события для передачи сообщений. Примером может служить создание EventEmitter

Последний - это просто способ использовать встроенную браузерную систему событий DOM вручную. Это в основном использует API событий DOM 3 , который изначально существует в (компетентных / современных) браузерах.

Так что вопрос просто в том, что вы хотите сделать? Выстреливаете события DOM или используете события для передачи сообщений?

Тест, показывающий пользовательские события DOM 3, на 98% медленнее

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

Если вам не нужны какие-либо функции событий DOM3, используйте библиотеку pub / sub.

[Изменить 2]

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

Будьте осторожны, если вы сделали это асинхронным, вы «потеряете» гарантию того, что обработчики событий выполнили свою логику после возврата вызова emit / trigger / dispatch. Это требует совершенно другого дизайна высокого уровня, чем предположение, что источники событий являются синхронными. Это не выбор, чтобы сделать слегка

Answer 2

Есть плюсы и минусы для каждого.Используйте то, что вам подходит.

Самым очевидным "против" использования методов DOM является то, что они привязаны к развертыванию на основе браузера и вовлекают DOM во что-то, даже если это не имеет смысла (например,обмен сообщениями не связан с объектами DOM), тогда как стандартная реализация в стиле Observer может использоваться в любой среде, не только в веб-браузерах, и с любыми общими объектами, которые вам нравятся.

Самым очевидным "против" создания собственной реализации Observer является то, что вы выполнили свою собственную реализацию Observer вместо того, чтобы повторно использовать что-то уже существующее (протестированное, отлаженное, оптимизированное и т. Д.) В среде.

Answer 3

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

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