Nodarbībā demonstrēju piemēru, kā var izmantot paštaisītiem DOM elementiem paredzētu notikumu apstrādes mehānismu. Es arī brīdināju, ka tas ir hack, ka izmantot iebūvētās EventTarget un CustomEvent klases nav laba prakse, ja runa ir par ne-DOM elementiem. Kā šajā gadījumā — spēles modelis CukasGame nav kas tāds, kam piemīt reprezentācija pārlūkprogrammas lapā.
Te ir šis koda paraugs:
class MyObject extends EventTarget {
constructor(name) {
super();
this.name = name;
}
trigger(message) {
const e = new CustomEvent('update', {detail: {message}});
this.dispatchEvent(e);
}
}
const o = new MyObject('Good Boy');
o.addEventListener('update', e => {
console.log(e.type, 'type event by', e.currentTarget.name, 'was triggered, message:', e.detail.message);
});
o.trigger('Hello');
Uzdevums ir pagatavot alternatīvas klases EventTarget un CustomEvent, kurām tiktu ieviestas minimāli nepieciešamās metodes (vienmēr var vēlāk papildināt!), un kuras var tālāk izmantot CukasGame pārvēršanā par notikumus ģenerējošiem objektiem.
Ierosinu to visu glabāt failā vanillaEvent.js, un klases saukt VEventTarget un VEvent. Izmantojot jaunradītās klases, augstāk redzamajam koda piemēram būtu jāfunkcionē identiski:
VEventTarget klasei (no kuras caur extend manto mūsu MyObject klase) ir addEventListener metode, kas pieņem divus argumentus: string notikuma tipu, un funkciju - notikuma apstrādātāju;
VEventTarget klasei ir dispatchEvent(e) metode, kas pieņem vienu argumentu - VEvent tipa objektu. Metodes izsaukšanas rezultātā tiek izauktas visas notikumu apstrādes funkcijas, kas pierakstījušās uz konkrētā tipa notikumiem;
Neobligāti, bet var arī vienkārši ieviest: VEventTarget klasei removeEventListener metodi, kas, līdzīgi addEventListener metodei, pieņem argumentos tipu un funkciju;
VEvent klasei jāievieš type, currentTarget un detail lauki.
Testēšanai vēlams izmantot vismaz divu dažādu tipu notikumus un vismaz divas dažādas notikumu apstrādes funkcijas.
Nodarbībā demonstrēju piemēru, kā var izmantot paštaisītiem DOM elementiem paredzētu notikumu apstrādes mehānismu. Es arī brīdināju, ka tas ir hack, ka izmantot iebūvētās EventTarget un CustomEvent klases nav laba prakse, ja runa ir par ne-DOM elementiem. Kā šajā gadījumā — spēles modelis CukasGame nav kas tāds, kam piemīt reprezentācija pārlūkprogrammas lapā.
Te ir šis koda paraugs:
Uzdevums ir pagatavot alternatīvas klases EventTarget un CustomEvent, kurām tiktu ieviestas minimāli nepieciešamās metodes (vienmēr var vēlāk papildināt!), un kuras var tālāk izmantot CukasGame pārvēršanā par notikumus ģenerējošiem objektiem.
Ierosinu to visu glabāt failā vanillaEvent.js, un klases saukt VEventTarget un VEvent. Izmantojot jaunradītās klases, augstāk redzamajam koda piemēram būtu jāfunkcionē identiski:
extendmanto mūsu MyObject klase) ir addEventListener metode, kas pieņem divus argumentus: string notikuma tipu, un funkciju - notikuma apstrādātāju;Testēšanai vēlams izmantot vismaz divu dažādu tipu notikumus un vismaz divas dažādas notikumu apstrādes funkcijas.