Koska puhuimme juuri tapahtumista, on nyt hyvä aika mainita mukautetut tapahtumat. Kaikki tähän mennessä puhuneet tapahtumat ovat niin sanottuja ”todellisia” tapahtumia. DOM: sta peräisin olevat tapahtumat todellisten tapahtumien perusteella, kuten napsautus tai näppäimen painallus. Nämä tapahtumat voidaan "laukaista" keinotekoisesti jQueryssä. Esimerkiksi "väärennös" napsauttamalla painiketta, voit tehdä:
$("#some-button").trigger("click");Sitten kaikki kyseiseen painikkeeseen sidotut napsautusten käsittelijät käynnistyvät ikään kuin käyttäjä todella napsauttaisi kyseistä painiketta. Mutta entä jos tekisimme:
$("#some-button").trigger("dance");Mitä sitten tapahtuu? "Tanssi" ei ole "todellinen" tapahtuma. Mutta virhettä ei heitetä. Se tapahtuu vain niin, että tuolin käsittelijöitä ei todennäköisesti ole sidottu tähän painikkeeseen. Mutta voisi olla ja olennaisesti mikä on mukautettu tapahtuma. Tapahtuma, jonka nimi on vain meikki.
Miksi tekisit niin? Lähinnä organisatoriset syyt. Ehkä haluat erottaa JavaScriptin, joka käsittelee tapahtumia ja toimintoja, sekä JavaScriptin, joka käsittelee tietoja ja hallinnollisia asioita. Se on hyvin kohtuullista. Jos tämä painike olisi ehkä "Tallenna asetukset" -painike, voit yksinkertaisesti käynnistää mukautetun tapahtuman nimeltä "tallenna asetukset" ja muualla on käsittelijä, joka odottaa tapahtuman käynnistymistä ja tallentaa todellisen datan. Sitä teimme olennaisesti videon esimerkissä.
Toinen mukautettujen tapahtumien käyttötapaus on yleisten käyttöliittymäkomponenttien kirjoittaminen. Puhun siitä tässä blogikirjoituksessa.
Ehkä luot harmonikkaefektin käyttöliittymäkomponenttina. Harmonikka tekee mitä tahansa harmonikkaa, avaa ja sulkee paneelit napsautuksilla / napautuksilla. UI-komponenttisi tekee sen erittäin hienosti. Nyt tätä harmonikkaa käyttävällä kehittäjällä voi olla erityisiä ja ainutlaatuisia asioita, joita he haluavat tapahtua sen kanssa. Oletetaan, että he käyttävät harmonikkaa tiliasetuksissa, ja kun käyttäjä sulkee paneelin, he haluavat tallentaa tiedot kyseisen paneelin lomake-elementeistä. Perinteinen malli saattaa olla, että kyseisen harmonikan käyttöliittymäkomponentin kirjoittaja tarjoaa soittotoimintoja, kun kyseinen toiminto tapahtuu. Kun alustat harmonikan, syötät takaisinsoittotoiminnot, jotka haluat kutsua, kun nuo asiat tapahtuvat. Se on yksi tie alaspäin. Toinen tie olisi se, että harmonikka vain laukaisisi mukautetut tapahtumat automaattisesti kaikissa asiaankuuluvissa toiminnoissaan.Kun paneeli sulkeutuu, se voi laukaista apanelClosedtapahtuma itse harmonikkaelementissä. Sitten sen kanssa työskentelevät kehittäjät voisivat vain sitoutua näihin tapahtumiin. Se on vain yksi tie, jota voit mennä organisaation syistä, jotka voivat olla melko tyylikkäitä.