ugrás a tartalomhoz

JavaScript Eseménykezelésre API, technikai kérdés

Karvaly84 · 2013. Már. 1. (P), 08.50
Helló guruk!

Csak ha ráértek, akkor szánjatok rám egy kis időt :)

A napokban ötlöttem ki hogy két JavaScript-es kis könyvtáramat egybe olvasszam, mert nagyon hasonló funkciót látnak el. Az egyik könyvtár DOM elemek böngészőfüggetlen eseménykezelésével foglalkozik. A másik meg ugyan ezt csinálja csak nem DOM elemekre koncentrál, hanem bármilyen objektumra. Konkrétan azt követtem el, hogy lemásoltam a DOM Event Model-t. Van Event, EventListener, EventTarget osztály, dispatchEvent(), stopPropagation() metódus, meg ilyen alap dolgok.

A DOM elemeknek egy statikus függvénnyel álltok be listener-t, a JavaScript objektumoknak meg úgy h származtatom az osztályukat az EventTarget-ből, és így lesz nekik tagfüggvénye a feladatra.

A következőkben arra gondoltam, hogy kiveszem a történetből az EventTarget osztályt, és statikus függvényekkel végzem a DOM, és JavaScript objektumok eseménykezelését is közös API-val. Két lehetőséget látok magam előtt:

1. A DOM események neveit kigyűjtöm arra az esetre, amikor böngésző eseményre állítok listener-t, és hagyom, hogy a böngésző maga tárolja a gyűjteményébe a listener-eket a DOM objektumoknál. Ez biztos gyorsabb, mint a második lehetőség, de ekkor az eseménylistát állandóan karban kel tartanom.

2. Nem gyűjtök ki semmit. Ekkor úgy járnék el, hogy egy tömböt hozzárendelek minden objektumhoz, amikor az első listener-t beállítom. A DOM objektumok-hoz feliratkozok az adott eseményre de csak egyszer, egy olyan eseménykezelővel ami ki értesíti a gyűjteményben lévő listener-eket. Poetro linkelte valamelyik nap be nekem a CustomEvent specifikációt, és ennek segítségével meg is lehetne oldani, mert bár ismertem egy régebbi verzióját, de utána nézve jobban a témának Explorerben is működik egy nem szabványos felület.

A 2. módszerrel kapcsolatban lenne pár kérdésem, és érdekelne a meglátásotok, mint JavaScript nindzsák.

Mennyire lassít az a megoldás, hogy a DOM objektumokhoz feliratkozott eseményfigyelőket egy tömbben tárolom és azokon megyek végig esemény bekövetkezésére? Nyilván kevés az eset amikor ez számítana, de mi van ha elméletben mondjuk 100 vagy 1000 eseményfigyelő van beállítva egy eseményhez?

Mindenféle hozzáoszlásnak örülnék, leugatástól a hajráig :D
 
1

Mire jó?

Hidvégi Gábor · 2013. Már. 1. (P), 09.58
A DOM elemek böngészőfüggetlen eseménykezelését kb. tízsoros nagyságrendű függvénnyel meg lehet oldani; az persze picit több kódot igényel, ha saját magad szeretnéd megoldani a feliratkozást, de azzal az előnnyel jár, hogy könnyebb lesz a hibakeresés (könnyű utánajárni, kik figyelnek az eseményre).

A másik, hogy JS objektumok hasonló eseménykezelésének nem sok értelmét látom. Így ugye egy absztrakciót vezetsz be, egy egyszerű példán keresztül:
Objektum.on('change', function on_objektum_change(_ertek) {
  fuggveny();
});

Objektum.value = 20;
(itt lefut a megfelelő callback)

Ezzel ekvivalens a hagyományos mód:
function objektum_ertek(_objektum, _ertek) {
  fuggveny();
}

objektum_ertek(Objektum, 20);

A kettő között a különbség kozmetikai, az első talán szebbnek tűnik, csak kell mellé egy csomó kód, hogy működjön (plusz hibázási lehetőség), az utóbbi meg megy befektetés nélkül.

Szerintem nem kell elbonyolítani, dobd ki nyugodtan az egészet, minél egyszerűbb, annál jobb.
2

A kettő között a különbség

Poetro · 2013. Már. 1. (P), 10.18
A kettő között a különbség kozmetikai, az első talán szebbnek tűnik, csak kell mellé egy csomó kód, hogy működjön (plusz hibázási lehetőség), az utóbbi meg megy befektetés nélkül.

Igen, ha csak pontosan egy függvényt kell meghívnod, és azt előre tudod. De mennyivel szebb, ha ahogy a kódod fejlődik, és például egyre több widgetet vezetsz be, azok fel tudnak iratkozni egymás eseményére, és reagálni tudnak rá, anélkül, hogy hozzá kellene nyúlni az eredeti objektumhoz, ami kiváltja az eseményeket.
4

Ha

Hidvégi Gábor · 2013. Már. 1. (P), 11.07
Ha az a ha ott ne lett volna : ) Egyébként igazatok van, feladata válogatja.
3

tight coupling

blacksonic · 2013. Már. 1. (P), 10.31
Azért a kozmetikai dolgokon túl más előnye is van neki.
Az első példánál a két kódrészlet között laza csatolás jön létre, míg másiknál összedrótozod...pár sorral kevesebb kód meg kicsit kevesebb absztrakció, cserébe nehezebben karbantartható
5

A DOM elemek

inf · 2013. Már. 1. (P), 21.28
A DOM elemek böngészőfüggetlen eseménykezelését kb. tízsoros nagyságrendű függvénnyel meg lehet oldani; az persze picit több kódot igényel, ha saját magad szeretnéd megoldani a feliratkozást, de azzal az előnnyel jár, hogy könnyebb lesz a hibakeresés (könnyű utánajárni, kik figyelnek az eseményre).


Ennél azért picit összetettebb a probléma, attól függően, hogy ie7, ie8 támogatást is akar beletenni az ember, vagy sem... Szinte mindennek más a neve, még az eseményeknek is. Pl w3c: oninput, ie: onpropertychange + if (property == "value"), vagy e.offsetX vs e.layerX, és még lehetne sorolni. Gondolom az újabb verzióknál már közeledtek az elnevezések egymáshoz. Egy ideje már nem foglalkozom a témával, inkább használok egy keretrendszert, amiben ezek benne vannak, és egyébként ezt javaslom másoknak is...

Sima objektumoknál akkor jó az eseménykezelés, ha nagyon általános kódot írsz, így szükség van a laza csatolásra, vagy aszinkron műveletet hajt végre a kódod, és arra kell eseménykezelőt tenned, de akár még olyan is lehet, hogy egy DOM eseménykezelőt burkolsz be vele magasabb absztrakciós szintről... Szóval annyira nem lényegtelen.