Da vi lige har talt om begivenheder, er det nu et godt tidspunkt at nævne brugerdefinerede begivenheder. Alle de begivenheder, som vi hidtil har talt om, er så at sige ”rigtige” begivenheder. Begivenheder, der stammer fra DOM baseret på virkelige ting, der sker, som et klik eller et tastetryk. Disse begivenheder kan "udløses" kunstigt i jQuery. For at "falske" et klik på en knap kan du f.eks .:
$("#some-button").trigger("click");Derefter vil enhver klikhåndterer, der er bundet til denne knap, affyres, som om en bruger virkelig klikkede på den knap. Men hvad hvis vi gjorde:
$("#some-button").trigger("dance");Hvad sker der så? "Dans" er ikke en "rigtig" begivenhed. Men ingen fejl vil blive kastet. Det sker bare så, at der sandsynligvis ikke er nogen "dans" -handlere bundet til den knap. Men der kunne være, og det er egentlig, hvad en brugerdefineret begivenhed er. En begivenhed med et navn, som du lige sammensætter.
Hvorfor ville du gøre det? For det meste organisatoriske grunde. Måske kan du lide at adskille din JavaScript, der håndterer begivenheder og handlinger, og din JavaScript, der håndterer data og administrative ting. Det er meget rimeligt. Hvis denne knap måske var en “Gem indstillinger” -knap, kunne du bare affyre en brugerdefineret begivenhed med navnet “gemme-indstillinger” og andre steder have en håndterer, der venter på, at begivenheden udløses og foretager den faktiske lagring af data. Det er i det væsentlige hvad vi gjorde i eksemplet fra videoen.
En anden brugssag til tilpassede begivenheder er at oprette generiske brugergrænseflade-komponenter. Jeg taler om det i dette blogindlæg.
Måske opretter du en harmonikaeffekt som en UI-komponent. Harmonikaen gør hvad alle harmonikaer til, åbner og lukker paneler på klik / vandhaner. Din UI-komponent gør det meget pænt. Nu kan en udvikler, der bruger dette harmonika, have specielle og unikke ting, som de ønsker at ske med det. Sig, at de bruger harmonika til kontoindstillinger, og når en bruger lukker et panel, vil de gemme dataene fra formelementerne i panelet. En traditionel model kan være, at forfatteren af den harmonika UI-komponent tilbyder tilbagekaldsfunktioner, når den handling sker. Når du initialiserer harmonikaen, sender du tilbagekaldelsesfunktioner, som du vil have kaldt, når disse ting sker. Det er en vej at gå ned. En anden vej ville være, at harmonikaen automatisk automatisk affyrede brugerdefinerede begivenheder for alle de relevante handlinger, den gør.Når panelet lukkes, kan det affyre enpanelClosedbegivenhed på selve harmonika-elementet. Derefter kunne udviklere, der arbejder med det, bare binde til disse begivenheder. Det er bare en anden vej, du kan gå ned af organisationsmæssige årsager, der kan være ret elegante.