Поскольку мы только что говорили о событиях, сейчас самое время упомянуть о пользовательских событиях. Все события, о которых мы говорили до сих пор, являются, так сказать, «настоящими» событиями. События, возникающие в DOM, основаны на реальных событиях, таких как щелчок или нажатие клавиши. Эти события могут быть искусственно «запущены» в jQuery. Например, чтобы «имитировать» нажатие кнопки, вы можете:
$("#some-button").trigger("click");
Тогда любые обработчики кликов, привязанные к этой кнопке, будут срабатывать, как если бы пользователь действительно нажал на эту кнопку. Но что, если бы мы сделали:
$("#some-button").trigger("dance");
Что тогда происходит? «Танец» - это не «настоящее» событие. Но ошибки не будет. Так уж случилось, что, вероятно, к этой кнопке не привязаны какие-либо обработчики «танцев». Но может быть, и это, по сути, и есть настраиваемое событие. Событие с названием, которое вы только что придумали.
Почему ты бы так поступил? В основном по организационным причинам. Возможно, вам нравится разделять свой JavaScript, который обрабатывает события и действия, и ваш JavaScript, который обрабатывает данные и административные вещи. Это очень разумно. Если бы эта кнопка была, возможно, кнопкой «Сохранить настройки», вы могли бы просто запустить пользовательское событие с именем «save-settings», а в другом месте иметь обработчик, который ожидает запуска этого события и выполняет фактическое сохранение данных. По сути, это то, что мы сделали в примере из видео.
Другой вариант использования настраиваемых событий - создание общих компонентов пользовательского интерфейса. Я говорю об этом в этом блоге.
Возможно, вы создаете эффект аккордеона как компонент пользовательского интерфейса. Аккордеон делает то же, что и все аккордеоны, открывает и закрывает панели по щелчку / нажатию. Ваш компонент пользовательского интерфейса делает это очень хорошо. Теперь разработчик, который использует этот аккордеон, может иметь особые и уникальные вещи, которые он хочет с ним сделать. Допустим, они используют гармошку для настроек учетной записи, и когда пользователь закрывает панель, они хотят сохранить данные из элементов формы на этой панели. Традиционная модель может заключаться в том, что автор этого компонента UI-аккордеона предлагает функции обратного вызова, когда это действие происходит. Когда вы инициализируете аккордеон, вы передаете функции обратного вызова, которые вы хотите вызывать, когда это происходит. Это одна дорога, по которой нужно спускаться. Другой способ - аккордеон просто автоматически запускает пользовательские события для всех соответствующих действий, которые он выполняет.Когда эта панель закроется, она может запуститьpanelClosed
событие на самом элементе аккордеона. Затем разработчики, работающие с ним, могли просто привязаться к этим событиям. Это просто еще один путь, по которому можно пойти по организационным причинам, который может быть довольно элегантным.