Deoarece tocmai am vorbit despre evenimente, acum este un moment bun pentru a menționa evenimentele personalizate. Toate evenimentele despre care am vorbit până acum sunt evenimente „reale” ca să spunem așa. Evenimente care își au originea în DOM pe baza unor lucruri reale care se întâmplă, cum ar fi apăsarea unui clic sau a unei taste. Aceste evenimente pot fi „declanșate” artificial în jQuery. De exemplu, pentru a „falsifica” un clic pe un buton, puteți face:
$("#some-button").trigger("click");Apoi, orice handler de clic legat de acel buton va declanșa ca și cum un utilizator ar fi dat clic pe acel buton. Dar dacă am face:
$("#some-button").trigger("dance");Ce se întâmplă atunci? „Dansul” nu este un eveniment „real”. Dar nu va fi aruncată nicio eroare. Se întâmplă că probabil nu există niciun handler „de dans” legat de acel buton. Dar ar putea exista și asta este în esență ceea ce este un eveniment personalizat. Un eveniment cu un nume pe care tocmai îl alcătuiești.
De ce ai face asta? Mai ales motive organizatorice. Poate că vă place să separați codul JavaScript care gestionează evenimente și acțiuni și codul JavaScript care gestionează date și lucruri administrative. Este foarte rezonabil. Dacă acest buton ar fi probabil un buton „Salvare setări”, puteți pur și simplu să declanșați un eveniment personalizat numit „salvare-setări” și în altă parte să aveți un handler care așteaptă ca acel eveniment să se declanșeze și să facă salvarea efectivă a datelor. În esență, asta am făcut în exemplul din videoclip.
Un alt caz de utilizare pentru evenimente personalizate este crearea componentelor UI generice. Vorbesc despre asta în această postare de blog.
Poate că creați un efect de acordeon ca componentă UI. Acordeonul face ceea ce toate acordeoanele, deschide și închide panourile prin clicuri / atingeri. Componenta dvs. UI face asta foarte frumos. Acum, un dezvoltator care folosește acel acordeon ar putea avea lucruri speciale și unice pe care vor să se întâmple cu el. Spuneți că utilizează acordeonul pentru setările contului și, atunci când un utilizator închide un panou, vrea să salveze datele din elementele formularului din acel panou. Un model tradițional ar putea fi pentru autorul acelei componente UI acordeon pentru a oferi funcții de apel invers atunci când acțiunea se întâmplă. Când inițializați acordeonul, treceți în funcțiile de apel invers pe care doriți să le apelați atunci când se întâmplă aceste lucruri. Acesta este un drum de coborât. Un alt drum ar fi ca acordeonul să declanșeze automat evenimente personalizate pentru toate acțiunile relevante pe care le face.Când panoul respectiv se închide, ar putea trage unpanelClosedeveniment pe elementul acordeon în sine. Atunci dezvoltatorii care lucrează cu acesta s-ar putea lega de acele evenimente. Este doar un alt drum pe care îl puteți merge din motive de organizare, care pot fi destul de elegante.