[JS] Overhaul van Scott Andrew's addEvent

[crisp]

De meesten van jullie weten waarschijnlijk wel eea van event-handling in JS, en van de verschillende event-models.

Zo heb je de DOM level 0 method die werkt in bijna alle browsers:

JavaScript:

element.onevent = function;

of inline:

HTML:

<element onevent="function()">

Nadeel van deze methode is dat je dynamisch maar 1 handler per object/event type kan opgeven.

Daarnaast heb je de DOM level 2 method die werkt in recente standards-compliant browsers:

JavaScript:

element.addEventListener(eventType, function, useCapture);

Deze methode ondersteund naast event bubbling ook event capturing, maar grootste nadeel is dat het niet werkt in non-standards compliant browsers (zoals Internet Explorer).

Internet Explorer zou niet van Microsoft zijn als het niet een eigen propriety event model zou hebben; ik noem dat het IE5 event model:

JavaScript:

object.attachEvent('on' + eventType, function);

Het grootste nadeel van het IE5 event model is dat de functie (handler) niet wordt uitgevoerd in de scope van het element waar het event op plaatsvond, maar binnen de scope van het window object. Het is dus niet mogelijk te achterhalen welk element precies het event triggerde. In de voorgaande 2 modellen kan dat wel dmv het 'this' keyword.
Nog een ander nadeel van dit model is dat de functies niet in volgorde van toekenning worden uitgevoerd, maar (volgens MSDN) in 'random' order - in de praktijk blijkt dat de laatst toegekende handler als eerste wordt aangeroepen itt de executie-volgorde van addEventListener.
Daarnaast ondersteund het IE5 model geen event capturing (maar dat is van minder geschikt belang in de meeste situaties).

Nu heeft Scott Andrew al in 2001 een wrapper geschreven waarmee je cross-browser eventhandlers kan toekennen aan elementen. Anno 2005 komt PPK er achter dat deze methode toch wel wat nadelen heeft, voornamelijk mbt de scope waarin de handlers worden uitgevoerd. een beetje JS-devver wist dat natuurlijk allang en heeft nooit omgekeken naar de methode van Scott Andrew

Anyway, PPK heeft aan de hand van de comments op zijn verhaal bedacht dat het tijd was voor een contest: herschrijf add/removeEvent dusdanig dat het de meeste tekortkomingen opheft.

Ik heb uiteraard al een entry gemaakt (zie ook de comments), maar wellicht zijn er hier nog mensen die het beter kunnen

In ieder geval biedt PPK geen ruimte voor discussie, dus dat kan dan mooi hier

[ Voor 15% gewijzigd door crisp op 10-09-2005 02:12 ]

[djluc]

Leuk idee zo'n contest, aan de resultaten hebben veel mensen iets, dat is wel erg mooi!

crisp: Je voorbeeldje werkt niet 100%. In FF blijft het 1e items van de submenu soms geel als je naar de items er onder gaat.

[crisp]

De handling functies voor het menu zijn geschreven door PPK en volgens de regels mocht je die niet wijzigen. Ze zijn niet helemaal je-van-het, dus het menu werkt daarom ook niet perfect...

Ik heb hier nog wel een goed werkend voorbeeld van een multi-level uitklapmenu (deze gebruikt gewoon DOM level 0 event handlers).

[ Voor 34% gewijzigd door crisp op 10-09-2005 12:41 ]

[crisp]

Weinig reacties nog, valt me een beetje tegen...

Anyway, een punt waarbij je hier goed op moet letten is memory-leaks in (met name) Internet Explorer.
Veel oplossingen gebruiken zogenaamde closures met anonymous functions; als je een anonymous function aan een DOM-object hangt, en die functie heeft een directe referentie naar een DOM object (hetzij hetzelfde object, hetzij een ander object) dan kan je problemen krijgen met circular references die IE bij unload niet opruimt. Voornamelijk de eerste 3 entries hebben daar last van.

Een aardige tool om dit soort lekken op te sporen is Drip.

Voor PPK was een bepaald menuscript de aanleiding om addEvent te gaan gebruiken. Ik denk dat zijn denkwijze hier echter verkeerd was. PPK was van mening dat het aantal eventhandlers in zijn geval aanleiding was tot memory-problemen, en dat IE die handlers bij onload niet netjes opruimde.
Dat laatste is waar, maar heeft imho een oorzaak die PPK over het hoofd ziet: ik denk persoonlijk dat het gebruik van anonymous functions daar het probleem is; dit lekt namelijk al memory in IE:

JavaScript:

function load()
{
    var foo = document.getElementById('foo');
    foo.onmouseover = function() { this.className='over'; }
}
window.onload = load;

Vervang je de anonymous function daarentegen door een reference naar een bestaande functie dan heb je het probleem al opgelost:

JavaScript:

function load()
{
    var foo = document.getElementById('foo');
    foo.onmouseover = mouseover;
}
window.onload = load;
  
function mouseover()
{
    this.className='over';
}

Zeker als het gaat om 224 eventhandlers is het veel effectiever om een referentie naar een bestaande functie te gebruiken (vooral als het elke keer dezelfde functie betreft), dan om voor elke handler een anonymous functie te gebruiken die als closure wordt behandelt (toegeven, dat is een bug in IE) door het 'this' keyword - wat uiteindelijk een DOM-reference is.
Kortom: PPK ziet in eerste instantie de oorzaak van het probleem niet en in plaats van een hamer pakt hij een drilboor om het probleem te lijf te gaan en komt er vervolgens achter dat dat toch ook niet het gewenste effect heeft. Zelfs al had addEvent niet de problemen gehad mbt het 'this'-keyword, dan had hij nog steeds memory-leaks gehad als hij dit had gedaan:

JavaScript:

addEvent(foo, 'mouseover', function () { this.className = 'over'; });

Je kan daar dan wel een eigen functie achter hangen die bijhoud welke events geregistreerd worden, en die bij unload weer verwijderen, maar dat is een workaround voor een probleem dat je in eerste instantie al had kunnen voorkomen...

[ Voor 8% gewijzigd door crisp op 12-09-2005 00:43 ]

[Woudloper]

crisp schreef op zaterdag 10 september 2005 @ 01:58:In ieder geval biedt PPK geen ruimte voor discussie, dus dat kan dan mooi hier

Heb helemaal een beetje het gevoel dat hij weinig discusieerd over de verschillende punten die hij ontdekt...

crisp schreef op zaterdag 10 september 2005 @ 10:58:
Ik heb hier nog wel een goed werkend voorbeeld van een multi-level uitklapmenu (deze gebruikt gewoon DOM level 0 event handlers).

Jammer, dat deze overigens gewoon DOM Level 0 event handlers gebruikt. Hij lijkt mij toch ook wel goed om de handler functies van PPK correct te schrijven, maar dan niet in je contest entry aangezien je daar niets mag aanpassen...

crisp schreef op maandag 12 september 2005 @ 00:38:
Weinig reacties nog, valt me een beetje tegen...

Denk dat dat o.a. te maken heeft met de tijden waarop je dit aan het posten bent en het feit dat je in het weekeind bezig bent. Zal doordeweeks wel meer reacties aankomen....

[...]

Een aardige tool om dit soort lekken op te sporen is Drip.

Dank hiervoor. Deze kende ik nog niet en is zeker handig voor mijn werk wat ik doe met javascript, hoewel dat de laatste tijd wel erg weinig is...

Voor PPK was een bepaald menuscript de aanleiding om addEvent te gaan gebruiken. Ik denk dat zijn denkwijze hier echter verkeerd was. PPK was van mening dat het aantal eventhandlers in zijn geval aanleiding was tot memory-problemen, en dat IE die handlers bij onload niet netjes opruimde.

Ik denk ook dat PPK een verkeerd voorbeeld aanhaalt voor het gebruik van addEvent(). Verder komt hij naar buiten met een ontdekking alsof hij het wiel uitgevonden heeft, maar het was (zoals jijzelf al zei) al veel langer bekend.

[Verwijderd]

Je moet er gewoon voor zorgen dat je elke mogelijke referentie die je tussen de DOM en JS plaatst ook op null zet. Het memory leak gebeuren is echt serieus aan het worden (ook bij de frameworks, op eentje na), en veel projecten stranden daar op.

[Verwijderd]

http://prototype.conio.net/

Volgens mij is dit zo'n beetje wat jullie willen bereiken. Deze library wordt op dit moment vooral gebruikt in Ruby on Rails. Het is slecht gedocumenteerd, maar werkt erg goed. Het is o.a. mogelijk transparant met dom en events te werken en om ajax requests te doen.

[Clay]

'k zag de contest eerder dan deze draad dus ik quote mezelf van daar ff hier maar:

Closures and circular references don't necessarily cause memory leaks; it's more a matter of cleaning up the mess you leave behind. There are enough articles out there about where leaks originate from, and what to do about them. And who's responsibility is it anyway? Why shouldn't we use a prefectly suited solution for a problem, just because the app leaks a bit of memory.

Since I'm violating guideline 1 and 2 with the following link, I guess I'm not competing The code, however, passes guideline 3 and 4, and clearly illustrates that the event fuctions and closures and circular references don't matter one bit in memory leakage if you clean them up onunload. And if you familiarize yourself a bit with the way scope works in javascript, it's basically a walk in the park to attach events in any way and any scope you see fit.

the link (see the source):
http://www.xs4all.nl/~peterned/events.html

Als je onunload dus gewoon je rommel opruimt lekt er zo goed als niets. Daar kom je ook niet omheen als je dikke ajaxriaspi apps gaat bouwen Closures en references zijn gewoon een gegeven in JS, en die moet je gewoon gebruiken als ze handig zijn (en dat zijn ze met die crappy scope van attachEvent), je moets ze niet schuwen omdat ze mogelijk memory lekken als je er niet netjes mee omgaat.

[Verwijderd]

Kan iemand mij uitleggen wat het voordeel is van een hele library voor eventhandling. Ik bedoel, 5 regels om addEventHandler en attachEvent te scheiden en je bent klaar. Als je echt met event handling wilt werken zul je toch echt wat kennis van de materie moeten vergaren buiten een framework om zodat je het goed kunt toepassen.

[Woudloper]

@ Gordijnstok: Je (in PPK zijn ogen offtopic) commentaar is alweer verwijderd uit de blogcomments bij PPK. Hoewel clay niet écht een contest entry heeft ingestuurd, maar hij wel gewoon blijven staan....

[Verwijderd]

hmz, dat hele memoryleak gebeuren is wel interessant, drip geeft al aan dat ik in m'n laatste projectje ook wel het een en ander bij te klussen heb.

[Verwijderd]

Woudloper schreef op maandag 12 september 2005 @ 11:24:
@ Gordijnstok: Je (in PPK zijn ogen offtopic) commentaar is alweer verwijderd uit de blogcomments bij PPK. Hoewel clay niet écht een contest entry heeft ingestuurd, maar hij wel gewoon blijven staan....

Als hij dat offtopic vond dat vraag ik me serieus af waar hij met zijn gedachten zat. Aangezien mem leaks nog steeds veelal door event handlers worden veroorzaakt. Maar als hij er lol in heeft, veel plezier zou ik zeggen. Had alleen niet verwacht dat hij er CensureMode.org van zou maken

[ Voor 7% gewijzigd door Verwijderd op 12-09-2005 12:10 ]

[Verwijderd]

Verwijderd schreef op maandag 12 september 2005 @ 11:36:
hmz, dat hele memoryleak gebeuren is wel interessant, drip geeft al aan dat ik in m'n laatste projectje ook wel het een en ander bij te klussen heb.

Het is zeker interessant, als je gaat merken in je projecten wat de impact kan zijn van een paar MB op de algehele performance van je browser. Schrikbarend als je ziet hoe snel een browser als een kaartenhuis in elkaar kan storten bij wat zwaardere interfaces en een relatief klein lek

Het wordt nog interessanter als er diverse DOM objecten zijn die een listener op elkaar hebben staan, en over verschillende window objects Leuk spul.

[ Voor 12% gewijzigd door Verwijderd op 12-09-2005 12:01 ]

[SuperRembo]

crisp schreef op maandag 12 september 2005 @ 00:38:
Anyway, een punt waarbij je hier goed op moet letten is memory-leaks in (met name) Internet Explorer.

Daar ben ik door schade en schande ook achter gekomen. M'n mooie ajax zoekfunctie vrat in IE 3 MB geheugen bij elke keer dat ie tevoorschijn kwam .

Om je rotzooi op te ruimen moet je wel weten wat je op moet ruimen. Ik zag zo snel niet hoe je een anonieme functie met behup van removeEventListener/detachEvent kon verwijderen, daarom ben ik maar gewoon overgestapt op DOM Level 0 event handlers. Simpel en doeltreffend. En toereikend in mijn geval.

[Verwijderd]

Maar daarmee kom je er niet, want een createElement toewijzen aan een JS object lekt ook geheugen als je deze niet opruimt. Aangezien de DOM in IE via COM is geimplementeerd en COM objecten in IE niet worden vrijgegeven als ze zijn verbonden met JS objects lekken deze ook. Google Maps lekte toen het voor het eerst op het web te zien was ook 6Mb per refresh, zelfs de knappe koppen bij Google hadden er dus schijnbaar wat moeite mee.

[ Voor 23% gewijzigd door Verwijderd op 13-09-2005 08:40 ]

[crisp]

Verwijderd schreef op dinsdag 13 september 2005 @ 08:39:
Maar daarmee kom je er niet, want een createElement toewijzen aan een JS object lekt ook geheugen als je deze niet opruimt. Aangezien de DOM in IE via COM is geimplementeerd en COM objecten in IE niet worden vrijgegeven als ze zijn verbonden met JS objects lekken deze ook.

Ik ben daar nu een beetje mee aan het stoeien, en het lijkt er op dat createElement inderdaad lekt maar alleen wanneer je elementen tijdens de renderingfase aanmaakt; als ik eea na de renderingfase aanroep (dmv window.onload) dan heb ik in een keer geen loze references meer

Edit: volgens mij is het een bugje in Drip; uiteindelijk zie ik geen increased memory als ik een pagina waar ik enkele duizenden elementen aanmaak met createElement een tigtal keer laat refreshen. Ook niet als ik referenties naar de objecten opsla in een global array (die ik dus niet opruim).

[ Voor 20% gewijzigd door crisp op 13-09-2005 12:01 ]

[Woudloper]

Ik zie net bij Quirksmode dat we helaas nog tot 4 oktober moeten wachten op de uitslag.

Heb even een paar entries bekeken, maar vond het jammer dat sommige elkaar code aan het gebruiken waren en aan het verbeteren...

[crisp]

en wat een sof: http://www.quirksmode.org...5/10/_and_the_winner.html

Ze kiezen een entry met serieuze drawbacks (memory-leaks en execution-order problemen), en herschrijven het naar iets dat niet eens meer werkt in IE

[Verwijderd]

Had je dan serieuze stukken kwalitatieve code verwacht? Clay is eruit gekicked vanwege een of andere wazige requirement, en de hele contest kwam op meerdere mensen ook over als "wij zullen wel even laten zien hoe je het moet doen". Dean Edwards heb ik dan diep respect voor, maar er zaten ook leden tussen waarvan ik dacht "zou ik daar door beoordeeld moeten worden?" Daarnaast, wat moet je er nu echt van maken, en wat is het nut ervan als je het toepast maar niet ervaart waarom en hoe je referenties en objecten moet disposen zodat ze opgeruimd kunnen worden.

Ik ben het zowiezo 100% met je eens dat het nogal frapant is dat een stuk script wint, wat vandaag de dag niet eens heeft rekening gehouden met leaks. Dit zegt dan meer over de algemene kwaliteit van de entries.

[ Voor 48% gewijzigd door Verwijderd op 18-10-2005 19:57 ]

[crisp]

Tsja, ik had er toch wel *iets* meer van verwacht, zeker omdat Dean erbij betrokken zou zijn. Dat laatste trek ik nu echter in twijfel...
PPK is sowieso niet zo'n JS-goeroe als hij pretendeerd te zijn, dat wist ik allang, maar een stuk code plaatsen dat niet eens werkt in IE (terwijl het daarvoor toch zo'n beetje bedoelt is omdat het de drawbacks van attachEvent zou moeten wegnemen)... tsja... hij klaagt continue over te weinig tijd, dus zal hij ws ook wel geen tijd hebben gehad om dit te testen...

En inderdaad, de manier waarop op quirksmode kritische posts verwijderd worden en er entries worden genegeerd vanwege bepaalde 'requirements' geeft natuurlijk ook wel te denken... (als requirements zo belangrijk zijn dan moet je geen script tot winnaar verkiezen als dat nog rework behoeft).
Ook Mark Wubben's entry werd eruit gekicked terwijl dat slechts een typo bleek te zijn... - hem zag ik toch ook wel als een kanshebber.

[ Voor 32% gewijzigd door crisp op 18-10-2005 20:29 ]

[Verwijderd]

Ik zie het ook niet echt als drawbacks. Mensen zijn nogal snel in staat om iets een drawback te noemen, terwijl het meer onjuist toepassen is. Zeker als je je wat dieper in de materie verdiept, en de achterliggende oorzaak van memory leaks ontdekt, weet je ook wat je moet doen en welke constructies je moet proberen te voorkomen.

Dat je daarvoor van goede huize moet komen dringt nog niet echt door in de community. Daar veranderd een contest als deze niets aan, omdat de context ervan - een managed oplossing creeren voor een memory leak probleem - niet wordt gecommuniceerd. En ja, als men niet weet wat de achterliggende diepere gedachte is van de context ...

Ze hadden dan beter een winnaar kunnen kiezen met bloated code, maar wel zonder memory leaks. Dan hadden bezoeker in ieder geval nog kunnen zien, "zo pak ik dus een situatie aan zonder memory leaks".

[Clay]

Clay is eruit gekicked vanwege een of andere wazige requirement, ...

Mwah, toen ik m'n comment maakte merkte ik er al bij op dat het waarschijnlijk niet mee zou dingen omdat ik idd de requirements aan mn laars lapte. Met de contest page kon je namelijk geen closures gebruiken, en wat ik aan wilde geven is dat dat inderdaad niet leakt als je het maar weer opruimt, al die wazige constructies zijn helemaal niet nodig. Naar mijn mening heb je alleen een try/catch nodig en volstaan addEventListener en attachEvent prima. Wat betreft guideline 4 zit de enige winst die er dan te behalen is in de hoeveelheid bytes die je nodig hebt, in wat whitespace en in de naam van je exception, maar inferiorBrowserException klinkt zo mooi

De opmerking:

Two more entries don't contain the mandatory test page (Peter Nederlof and Ismael Jurado). They're out of the race.

vind ik dan wel weer wat kort door de bocht, maar misschien ligt dat aan mij, en moet ik het wat minder vanzelfsprekend vinden dat er naar je geluisterd wordt (of er op zijn minst een discussie ontstaat) als je een goed argument hebt

Tenzij ik dement word durf ik trouwens ook te zweren dat de lijst met guidelines eerst 10 punten bevatte ipv 9, iets over niet mogen leaken. Maargoed ... Het idee van een contest als deze vind ik verder op zich wel leuk, maar ik had het zelf met een berg meer vrijheid en discussiemogelijkheden opgezet, je gaat mensen toch niet kunnen dwingen om het op een bepaalde manier te doen of te laten.

[crisp]

een wrapper voor attachEvent vind ik dus minderwaardig aangezien de event execution order daardoor niet gelijk is aan addEventListener. FIFO is logisch(er), en als je het gelijk wilt trekken tussen browsers dien je daar dus ook rekening mee te houden. Daarom heb ik attachEvent dus helemaal niet gebruikt en ben daarmee dus waarschijnlijk ook compatibeler met browsers als IE5/MAC en NS4* (waar PPK nu mee op de proppen komt terwijl dat geen voorwaarde was).

* not tested though

[Clay]

IE5 deed geloof ik idd niet aan attachEvent noch addEventListener, maar wie gebruikt dat nou nog. Ik zie ze ook geen captureEvents() meer doen voor NS4

[Verwijderd]

crisp schreef op dinsdag 18 oktober 2005 @ 20:50:
een wrapper voor attachEvent vind ik dus minderwaardig aangezien de event execution order daardoor niet gelijk is aan addEventListener. FIFO is logisch(er), en als je het gelijk wilt trekken tussen browsers dien je daar dus ook rekening mee te houden.

Hier mis ik even de gedachte erachter Waarom zou je de event execution order willen managen, in principe heeft geen van de events relaties met andere events, en zelfs dan is dat iets wat je in de function zou moeten afhandelen (decoupling)

Ik zie qua eventbubbling ook zo gauw niet in hoeverre dit problemen zou moeten opleveren, omdat de basis hiervan toch door de browser zelf wordt bepaald

[crisp]

Verwijderd schreef op dinsdag 18 oktober 2005 @ 21:40:
[...]


Hier mis ik even de gedachte erachter Waarom zou je de event execution order willen managen, in principe heeft geen van de events relaties met andere events, en zelfs dan is dat iets wat je in de function zou moeten afhandelen (decoupling)

Ik zie qua eventbubbling ook zo gauw niet in hoeverre dit problemen zou moeten opleveren, omdat de basis hiervan toch door de browser zelf wordt bepaald

Puur theoretisch zou je toch een voorkeur vwb execution order kunnen hebben, zelfs als de functies geen relaties tot elkaar hebben. Dat het in de praktijk amper voorkomt dat je meerdere functies aan hetzelfde event koppelt doet niet terzake

Er is trouwens nog een verschil; in de originele code van John Resig (ik haal die maar even aan aangezien PPKs versie helemaal niet werkt in IE (mbt scope that is) ) kan je 2x dezelfde functie aan een handler toekennen, terwijl dat met addEventListener niet kan; kortom:

JavaScript:

function myAlert() { alert('woei!'); }

var el = document.getElementById('foo');
addEvent(el, 'click', myAlert);
addEvent(el, 'click', myAlert);

zal in IE 2x een alert geven en in andere browsers maar 1x.

Ik heb de code van PPK zelf maar even gefixed maar zoals te verwachten viel lekt dat geheugen en heeft het nog steeds de eerder genoemde nadelen (die ik in mijn eigen entry al aanhaalde als pitfalls).

Ik ben heel benieuwd hoe PPK hierop gaat reageren...

[ Voor 43% gewijzigd door crisp op 19-10-2005 00:31 ]

[Verwijderd]

"Fixed for IE by Tino Zijdel" zo droog

[Verwijderd]

Hahaha, stelletje zuurpruimen Grumpy old coders.

Crisp, ik zat ff naar jouw oplossing te kijken; mooi werk Moest even een minuutje met m'n ogen knipperen toen ik dit zag:

code:

var evTypeRef = '__' + e.type, obj;

Ik dacht "wat is dat voor een vage assignment, met die komma?

Ik heb je code niet getest maar itereert for (var ref in this[evTypeRef]) niet ook door Array methods, e.d. heen? Ik ben altijd voorzichtig met for/in omdat de volgorde van de properties nergens is vastgelegd. In mijn (oude) JS/The Definitive Guide staat:

The for/in loop does not specify the order in which the properties of an object are assigned to the variable. There is no way to tell in advance, and the behavior may differ between implementations or versions of JavaScript.

[crisp]

Ja, ik hou ervan declaraties op 1 regel te zetten

vwb de for - in heb je wel gelijk, die itereert ook over prototyped methods heen dus dat kan idd problemen veroorzaken.
wat betreft de volgorde: vziw is het alleen Opera die niet in volgorde van assignment properties teruggeeft, in andere browsers is het toch FIFO (hoewel je gelijk hebt dat je daar niet helemaal van uit mag gaan). Dat zijn echter dingen die redelijk eenvoudig wel aan te passen zijn.

[crisp]

Aangepaste versie: http://therealcrisp.xs4all.nl/upload/addEvent2.html

[crisp]

En Dean Edwards heeft zelf ook iets gebakken. Ik zie overeenkomsten met mijn gestripte versie, en Dean ook

Het idee om een uniek ID toe te kennen aan de handlers is echt briljant.

[ Voor 15% gewijzigd door crisp op 20-10-2005 23:38 ]

[Verwijderd]

/me likes the dojo event package.. www.dojotoolkit.org

[crisp]

dojo gebruikt kortweg deze truuk:

JavaScript:

function addEvent(obj, evType, fn)
{
    var orgEvent = obj['on'+evType];
    if (orgEvent)
    {
        obj['on'+evType] = function()
        {
            orgEvent();
            fn();
        }
    }
    else
    {
        obj['on'+evType] = fn;
    }
}

Nadelen: mogelijke memory-leaks in IE en geen mogelijkheid om eventhandlers te verwijderen.

[Verwijderd]

Je kunt de eventhandlers natuurlijk alsnog op obj['on'+evType] = null zetten Maar het risico op references hou je eigenlijk altijd wel