Aangezien we het net over evenementen hadden, is dit een goed moment om aangepaste evenementen te noemen. Alle gebeurtenissen waarover we het tot nu toe hebben gehad, zijn zogezegd "echte" gebeurtenissen. Gebeurtenissen die hun oorsprong vinden in de DOM op basis van echte dingen die gebeuren, zoals een klik of toetsaanslag. Deze gebeurtenissen kunnen kunstmatig worden "geactiveerd" in jQuery. Als u bijvoorbeeld een klik op een knop wilt 'vervalsen', kunt u het volgende doen:
$("#some-button").trigger("click");Vervolgens worden alle klikhandlers die aan die knop zijn gekoppeld, geactiveerd alsof een gebruiker echt op die knop heeft geklikt. Maar wat als we het zouden doen:
$("#some-button").trigger("dance");Wat gebeurt er dan? "Dans" is geen "echte" gebeurtenis. Maar er zal geen fout worden gemaakt. Toevallig zijn er waarschijnlijk geen 'dans'-handlers aan die knop gebonden. Maar dat kan er zijn en dat is in wezen wat een evenement op maat is. Een evenement met een naam die je net verzint.
Waarom zou je dat doen? Meestal organisatorische redenen. Misschien wilt u uw JavaScript dat gebeurtenissen en acties afhandelt, en uw JavaScript dat gegevens en administratieve zaken afhandelt, scheiden. Dat is heel redelijk. Als deze knop misschien een "Save Settings" -knop was, zou je gewoon een aangepaste gebeurtenis met de naam "save-settings" kunnen afvuren en ergens anders een handler hebben die wacht tot die gebeurtenis wordt geactiveerd en de feitelijke gegevens opslaat. Dat is in wezen wat we deden in het voorbeeld uit de video.
Een ander gebruiksscenario voor aangepaste gebeurtenissen is het schrijven van generieke UI-componenten. Daar praat ik over in deze blogpost.
Misschien creëer je een accordeoneffect als een UI-component. De accordeon doet waar alle accordeons naar toe, opent en sluit panelen met klikken / tikken. Uw UI-component doet dat heel goed. Een ontwikkelaar die die accordeon gebruikt, heeft misschien speciale en unieke dingen die ze ermee willen laten gebeuren. Stel dat ze de accordeon gebruiken voor accountinstellingen, en wanneer een gebruiker een paneel sluit, willen ze de gegevens van de formulierelementen in dat paneel opslaan. Een traditioneel model kan zijn dat de auteur van die accordeon-UI-component callback-functies aanbiedt wanneer die actie plaatsvindt. Wanneer u de accordeon initialiseert, geeft u callback-functies door die u wilt gebruiken als die dingen gebeuren. Dat is een weg die we moeten inslaan. Een andere manier zou zijn dat de accordeon automatisch aangepaste evenementen afvuurt voor alle relevante acties die hij uitvoert.Wanneer dat paneel sluit, kan het eenpanelClosedevenement op het accordeonelement zelf. Ontwikkelaars die ermee werken, kunnen zich dan gewoon aan die gebeurtenissen binden. Het is gewoon een andere weg die u kunt inslaan om organisatorische redenen die behoorlijk elegant kunnen zijn.