Como acabamos de hablar de eventos, ahora es un buen momento para mencionar eventos personalizados. Todos los eventos de los que hemos hablado hasta ahora son eventos "reales", por así decirlo. Eventos que se originan en DOM basados en cosas reales que suceden, como un clic o presionar una tecla. Estos eventos se pueden "activar" artificialmente en jQuery. Por ejemplo, para "simular" un clic en un botón, puede hacer:
$("#some-button").trigger("click");Entonces, cualquier controlador de clic vinculado a ese botón se activará como si un usuario realmente hubiera hecho clic en ese botón. Pero, ¿y si lo hiciéramos?
$("#some-button").trigger("dance");¿Qué pasa entonces? "Bailar" no es un evento "real". Pero no se arrojará ningún error. Da la casualidad de que probablemente no haya ningún controlador de "baile" vinculado a ese botón. Pero podría haber y eso es esencialmente lo que es un evento personalizado. Un evento con un nombre que acabas de inventar.
¿Por qué harías eso? Principalmente razones organizativas. Quizás le guste separar su JavaScript que maneja eventos y acciones, y su JavaScript que maneja datos y cosas administrativas. Eso es muy razonable. Si este botón fuera quizás un botón "Guardar configuración", simplemente podría activar un evento personalizado llamado "guardar configuración" y en otro lugar tener un controlador que espera a que ese evento se active y guarde los datos. Eso es esencialmente lo que hicimos en el ejemplo del video.
Otro caso de uso de eventos personalizados es la creación de componentes de IU genéricos. Hablo de eso en esta publicación de blog.
Quizás esté creando un efecto de acordeón como componente de la interfaz de usuario. El acordeón hace lo que hacen todos los acordeones, abre y cierra paneles con clics / toques. Su componente de interfaz de usuario lo hace muy bien. Ahora, un desarrollador que usa ese acordeón puede tener cosas especiales y únicas que quiere que sucedan con él. Digamos que están usando el acordeón para la configuración de la cuenta, y cuando un usuario cierra un panel, quiere guardar los datos de los elementos del formulario en ese panel. Un modelo tradicional podría ser que el autor de ese componente de interfaz de usuario de acordeón ofrezca funciones de devolución de llamada cuando suceda esa acción. Cuando inicializa el acordeón, pasa las funciones de devolución de llamada que desea que se llamen cuando sucedan esas cosas. Ese es un camino por recorrer. Otro camino sería que el acordeón dispara automáticamente eventos personalizados para todas las acciones relevantes que realiza.Cuando ese panel se cierra, podría disparar unpanelClosedevento en el propio elemento acordeón. Entonces, los desarrolladores que trabajen con él podrían simplemente unirse a esos eventos. Es solo otro camino que puedes seguir por razones de organización que pueden ser bastante elegantes.