Комментарии 17
Теперь кроме стандартного EventEmitter из Node.js, EventEmitter2 от asyncly, EventEmitter-а из jQuery, сотни малопопулярных эмиттеров всех сортов и расцветок (написать Event Emitter — это как Hello World, только проще), теперь еще и DOM CustomEvent Emitter. Нет, оно, конечно, хорошо, но в зоопарке лишь прибыло, а профиты от решения в статье не раскрыты.
Т.к эвенты кастомные и их нужно вызывать самому, то в чем принципиальное отличие от:
// First create the function
function myFunction(){
console.log(«Woho!»)
}
// Trigger it!
myFunction();
На худой конец 20 строчный pubsub для jquery gist.github.com/cowboy/661855 выполнет роль event listener.
// First create the function
function myFunction(){
console.log(«Woho!»)
}
// Trigger it!
myFunction();
На худой конец 20 строчный pubsub для jquery gist.github.com/cowboy/661855 выполнет роль event listener.
Отличие в том, что события для DOM элементов могут «всплывать», таким образом их можно отловить на вышестоящем элементе. Также, нет необходимости знать название функции, чтобы «запустить» событие — особенно актуально это при замыканиях, когда событие запускается в одном месте, а отлавливается в другом. Обработчиков может и не быть, и генерация события не приведёт к ошибке. Также, можно повесить несколько обработчиков на событие, в вашем же случае с функцией придётся пилить что-то своё в виде стека или очереди обработчиков.
Хочется добавить, что кастомные события давно реализованы в jQuery, и это очень удобная штука.
Хочется добавить, что кастомные события давно реализованы в jQuery, и это очень удобная штука.
Я утрировал с вызовом функции на прямую. JQuery custom events — это старый добрый пабсаб, может только с небольшим сахаром и проседанием производительности под 20х раз.
Сравнительный тест: jsperf.com/pubsub-js-vs-jquery-events/12
Сравнительный тест: jsperf.com/pubsub-js-vs-jquery-events/12
jQuery почти никогда не являлся лидером в сравнении производительности, однако там есть большинство нужных вещей «из коробки», и всё это работает кроссбраузерно, так что нет необходимости подключать дополнительные библиотеки. К тому же навешивание и триггеринг кастомных событий не отличается от родных событий, что очень удобно для сопровождения кода.
Когда-то раньше я тоже гонялся за скоростью библиотек, но позже понял, что оптимизировать нужно только тогда, когда видно, что нужно оптимизировать. Как говорится, «предварительная оптимизация — зло». А когда на странице используется всего 5-10 элементов с кастомными событиями, пару мс задержки большой погоды не делают.
Если есть необходимость писать код без jQuery (или другой библиотеки), то, конечно же, использование вышеупомянутого pubsub будет как раз в тему. Однако я давно уже не встречал подобных требований в проектах, где больше ценится стабильность и поддержка сторонних библиотек.
Когда-то раньше я тоже гонялся за скоростью библиотек, но позже понял, что оптимизировать нужно только тогда, когда видно, что нужно оптимизировать. Как говорится, «предварительная оптимизация — зло». А когда на странице используется всего 5-10 элементов с кастомными событиями, пару мс задержки большой погоды не делают.
Если есть необходимость писать код без jQuery (или другой библиотеки), то, конечно же, использование вышеупомянутого pubsub будет как раз в тему. Однако я давно уже не встречал подобных требований в проектах, где больше ценится стабильность и поддержка сторонних библиотек.
Зато к стеку/очереди можно организовать доступ, а получить список навешенных на событие обработчиков невозможно.
получить список навешенных на событие обработчиков невозможно
jQuery же получает как-то, значит возможно :)
Когда я в 06-07 начинал карьеру джаваскриптера, как же мне хотелось триггерить кастомные события в DOM-дереве!..
Потом пришло понимание, что всю эту петрушку с событиями можно написать самому и что в любом случае надо отделять обработчики событий от логики — а, значит, иногда проще вызвать нужную функцию напрямую.
Возможно, в связи с грядущими веб-компонентами кастомные DOM-события снова станут играть большую роль.
Потом пришло понимание, что всю эту петрушку с событиями можно написать самому и что в любом случае надо отделять обработчики событий от логики — а, значит, иногда проще вызвать нужную функцию напрямую.
Возможно, в связи с грядущими веб-компонентами кастомные DOM-события снова станут играть большую роль.
Создание и инициация кастомных событий с передачей кастомных данных, это невероятно полезная вещь.
Вот с этого места бы и поподробнее, а вместо всего остального сгодилась бы и ссылка на MDN.
detail: {
username: "davidwalsh"
},
по-мойму это и есть кастомные данные. Не уверен насчёт того, как их получать «родным» способом, но в jQuery можно передавать дополнительные данные о событии вторым аргументом, либо зашить их в само генерируемое событие
jQuery(element).on('custom-event', function(){ console.log(arguments);});
jQuery(element).trigger('custom-event', {"detail":{"username":"davidwalsh"}});
В IE11 хоть и есть конструктор CustomEvent, но его нельзя использовать напрямую, поэтому кросс-браузерное решение выглядит так:
// First create the event
var myEvent = document.createEvent('CustomEvent');
myEvent.initCustomEvent('userLogin', false, false, {
username: 'davidwalsh'
});
// Trigger it!
myElement.dispatchEvent(myEvent);
Я не совсем понял в чем отличие от простого конструктора Event? Пример:
document.body.addEventListener('my_event', function () {
alert('hello');
});
document.body.dispatchEvent(new Event('my_event'));
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кастомные события JavaScript