# 14: Egendefinerte hendelser - CSS-triks

Anonim

Siden vi nettopp snakket om hendelser, er det nå en god tid å nevne tilpassede hendelser. Alle begivenhetene vi har snakket om så langt er så å si ”virkelige” hendelser. Hendelser som har sitt utspring i DOM basert på virkelige ting som skjer, for eksempel et klikk eller tastetrykk. Disse hendelsene kan "utløses" kunstig i jQuery. For å "falske" et klikk på en knapp kan du for eksempel gjøre:

$("#some-button").trigger("click");

Deretter vil alle klikkhåndterere som er bundet til den knappen, løsne som om en bruker virkelig klikket på den knappen. Men hva om vi gjorde det:

$("#some-button").trigger("dance");

Hva skjer da? “Dans” er ikke en “ekte” begivenhet. Men ingen feil vil bli kastet. Det skjer slik at det sannsynligvis ikke er noen "dans" -behandlere bundet til den knappen. Men det kan være, og det er egentlig hva en tilpasset begivenhet er. En begivenhet med et navn du bare lager.

Hvorfor ville du gjort det? For det meste organisatoriske årsaker. Kanskje du liker å skille JavaScript som håndterer hendelser og handlinger, og JavaScript som håndterer data og administrative ting. Det er veldig rimelig. Hvis denne knappen kanskje var en “Lagre innstillinger” -knapp, kan du bare slå av en egendefinert hendelse kalt “lagre innstillinger” og andre steder ha en behandler som venter på at hendelsen skal utløses og gjør den faktiske lagringen av data. Det er egentlig det vi gjorde i eksemplet fra videoen.

En annen brukssak for tilpassede hendelser er å lage generiske brukergrensesnittkomponenter. Jeg snakker om det i dette blogginnlegget.

Kanskje du lager en trekkspilleffekt som en UI-komponent. Trekkspillet gjør hva alle trekkspill til, åpner og lukker paneler på klikk / kraner. UI-komponenten din gjør det veldig bra. Nå kan en utvikler som bruker det trekkspillet ha spesielle og unike ting de ønsker å skje med det. Si at de bruker trekkspill for kontoinnstillinger, og når en bruker lukker et panel, vil de lagre dataene fra skjemaelementene i panelet. En tradisjonell modell kan være at forfatteren av den trekkspillgrensesnittkomponenten tilbyr tilbakekallingsfunksjoner når denne handlingen skjer. Når du initialiserer trekkspillet, sender du inn tilbakeringingsfunksjoner du vil ringe når disse tingene skjer. Det er en vei å gå ned. En annen vei ville være for trekkspillet å automatisk avfyr tilpassede hendelser for alle relevante handlinger den gjør.Når panelet lukkes, kan det avfyre ​​apanelClosedarrangement på selve trekkspillelementet. Da kan utviklere som jobber med det bare binde seg til disse hendelsene. Det er bare en annen vei du kan gå ned av organisasjonsgrunner som kan være ganske elegant.