Da wir gerade über Ereignisse gesprochen haben, ist jetzt ein guter Zeitpunkt, benutzerdefinierte Ereignisse zu erwähnen. Alle Ereignisse, über die wir bisher gesprochen haben, sind sozusagen „echte“ Ereignisse. Ereignisse, die im DOM auf realen Dingen basieren, die passieren, wie ein Klick oder ein Tastendruck. Diese Ereignisse können in jQuery künstlich „ausgelöst“ werden. Um beispielsweise einen Klick auf eine Schaltfläche zu „simulieren“, könnten Sie Folgendes tun:
$("#some-button").trigger("click");Dann werden alle Klick-Handler, die an diese Schaltfläche gebunden sind, ausgelöst, als ob ein Benutzer wirklich auf diese Schaltfläche geklickt hätte. Aber was wäre, wenn wir Folgendes tun würden:
$("#some-button").trigger("dance");Was passiert dann? „Tanz“ ist kein „echtes“ Ereignis. Aber es wird kein Fehler ausgelöst. Es ist nur so, dass es wahrscheinlich keine „Tanz“-Handler gibt, die an diese Schaltfläche gebunden sind. Aber es *könnte* welche geben, und das ist im Wesentlichen, was ein benutzerdefiniertes Ereignis ist. Ein Ereignis mit einem Namen, den Sie sich einfach ausdenken.
Warum sollten Sie das tun? Hauptsächlich aus organisatorischen Gründen. Vielleicht möchten Sie Ihr JavaScript, das Ereignisse und Aktionen verarbeitet, von Ihrem JavaScript trennen, das Daten und administrative Dinge verarbeitet. Das ist sehr vernünftig. Wenn diese Schaltfläche vielleicht eine Schaltfläche „Einstellungen speichern“ wäre, könnten Sie einfach ein benutzerdefiniertes Ereignis namens „save-settings“ auslösen und anderswo einen Handler haben, der darauf wartet, dass dieses Ereignis ausgelöst wird, und die eigentliche Datenspeicherung durchführt. Das ist im Wesentlichen das, was wir im Beispiel aus dem Video getan haben.
Ein weiterer Anwendungsfall für benutzerdefinierte Ereignisse ist die Erstellung generischer UI-Komponenten. Das bespreche ich in diesem Blogbeitrag.
Vielleicht erstellen Sie einen Akkordeon-Effekt als UI-Komponente. Das Akkordeon tut, was alle Akkordeons tun: Es öffnet und schließt Panels bei Klicks/Taps. Ihre UI-Komponente macht das sehr gut. Nun möchte ein Entwickler, der dieses Akkordeon verwendet, vielleicht spezielle und einzigartige Dinge damit machen. Sagen wir, sie verwenden das Akkordeon für Kontoeinstellungen, und wenn ein Benutzer ein Panel schließt, möchten sie die Daten aus den Formularelementen in diesem Panel speichern. Ein traditionelles Modell wäre, dass der Autor dieser Akkordeon-UI-Komponente Callback-Funktionen anbietet, wenn diese Aktion stattfindet. Wenn Sie das Akkordeon initialisieren, übergeben Sie Callback-Funktionen, die aufgerufen werden sollen, wenn diese Dinge passieren. Das ist eine Möglichkeit. Eine andere Möglichkeit wäre, dass das Akkordeon einfach automatisch benutzerdefinierte Ereignisse für alle relevanten Aktionen auslöst, die es durchführt. Wenn sich das Panel schließt, könnte es ein `panelClosed`-Ereignis für das Akkordeon-Element selbst auslösen. Dann könnten Entwickler, die damit arbeiten, einfach an diese Ereignisse binden. Es ist nur ein weiterer Weg, den Sie aus organisatorischen Gründen gehen können, der sehr elegant sein kann.