Dato che abbiamo appena parlato di eventi, ora è un buon momento per menzionare gli eventi personalizzati. Tutti gli eventi di cui abbiamo parlato finora sono eventi "reali" per così dire. Eventi che hanno origine nel DOM in base a cose reali che accadono, come un clic o la pressione di un tasto. Questi eventi possono essere "innescati" artificialmente in jQuery. Ad esempio, per "simulare" un clic su un pulsante, potresti fare:
$("#some-button").trigger("click");Quindi qualsiasi gestore di clic associato a quel pulsante si attiverà come se un utente avesse davvero fatto clic su quel pulsante. Ma se lo facessimo:
$("#some-button").trigger("dance");Cosa succede allora? "Dance" non è un evento "reale". Ma non verrà generato alcun errore. Accade così che probabilmente non ci siano gestori di "danza" legati a quel pulsante. Ma potrebbe esserci e questo è essenzialmente ciò che è un evento personalizzato. Un evento con un nome che ti sei appena inventato.
Perché dovresti farlo? Principalmente ragioni organizzative. Forse ti piace separare il tuo JavaScript che gestisce eventi e azioni e il tuo JavaScript che gestisce dati e cose amministrative. È molto ragionevole. Se questo pulsante fosse forse un pulsante "Salva impostazioni", potresti semplicemente attivare un evento personalizzato denominato "salva-impostazioni" e altrove avere un gestore che attende che l'evento si attivi e fa l'effettivo salvataggio dei dati. Questo è essenzialmente quello che abbiamo fatto nell'esempio del video.
Un altro caso d'uso per eventi personalizzati è la creazione di componenti dell'interfaccia utente generici. Ne parlo in questo post del blog.
Forse stai creando un effetto fisarmonica come componente dell'interfaccia utente. La fisarmonica fa quello che fanno tutte le fisarmoniche, apre e chiude i pannelli con clic / tocchi. Il tuo componente UI lo fa molto bene. Ora uno sviluppatore che usa quella fisarmonica potrebbe avere cose speciali e uniche che vuole che accadano con essa. Supponiamo che stiano utilizzando la fisarmonica per le impostazioni dell'account e quando un utente chiude un pannello, desidera salvare i dati dagli elementi del modulo in quel pannello. Un modello tradizionale potrebbe essere che l'autore di quel componente dell'interfaccia utente della fisarmonica offra funzioni di callback quando si verifica l'azione. Quando si inizializza la fisarmonica, si passano le funzioni di callback che si desidera vengano chiamate quando si verificano queste cose. Questa è una strada da percorrere. Un'altra strada sarebbe che la fisarmonica attivasse automaticamente eventi personalizzati per tutte le azioni pertinenti che esegue.Quando quel pannello si chiude, potrebbe sparare apanelClosedevento sull'elemento fisarmonica stesso. Quindi gli sviluppatori che lavorano con esso potrebbero semplicemente legarsi a quegli eventi. È solo un'altra strada che puoi percorrere per motivi di organizzazione che possono essere piuttosto eleganti.