News

Soundbyte 105: Don’t cross the streams

4 augustus 2013

Afgelopen week hadden we last van performance problemen. Een van de oorzaken bleek een jQuery plugin te zijn, die we in een AngularJS directive gewrapped hadden. De plugin zelf was er een die wel vaker gebruikt werd, en op het eerste gezicht zag de code er ook vrij behoorlijk uit. Echter bleek dat door het vele updaten vanuit Angular watches bepaalde zaken in deze plugin toch niet zo heel efficiënt gebeurden.

Ook wij waren in een (blijkbaar bekende) valkuil gestapt: het wrappen van jQuery plugins in Angular directives. Het lijkt op het eerste gezicht geen verkeerde aanpak, maar doe… het… niet… Veel jQuery plugins zijn niet geschreven met databinding in het achterhoofd, waardoor ze soms onnodige operaties op de DOM uitvoeren. Bovendien is het 9 van de 10 keer zeer eenvoudig om zelfs een complexe jQuery plugin volledig naar een Angular directive om te schrijven, waardoor je code ook nog overzichtelijker wordt. Dit en meer staat goed in deze StackOverflow post uitgeschreven, zeker de moeite waard om eens door te lezen.De les van afgelopen week: jQuery gebruiken in een AngularJS applicatie; niet doen, behalve wanneer je echt, echt…. echt geen andere uitweg meer ziet. Of, zoals een collega de Ghostbusters aanhaalde: “Don’t cross the streams”

Pile of Poo

Maar ik heb deze week nog iets nuttigs geleerd dat ik jullie zeker niet wil onthouden. Maandag was ik een web-applicatie aan het debuggen. In het netwerk verkeer zag ik requests voorbij komen met nogal aparte tekens. Het leken wel… drollen?! Na er wat dieper ingedoken te zijn (jaja), bleek het volgende aan de hand. We maken voor onze REST backend gebruik van Nancy. En zoals bij de meeste van dit soort frameworks, kun je ook hierin eenvoudig routes definiëren. In Nancy gaat dit ongeveer zo:

Get["Orders/{id}"] = parameters => GetOrders(parameters.id);

Wat zoiets betekent als: iedere GET request die binnenkomt op het pad Orders/{id} wordt afgehandeld door een functie GetOrders, waarbij het deel dat op de plek van {id} staat als parameter meegegeven wordt. Nu komt in sommige id’s binnen deze applicatie het # teken voor. Deze encoden we in onze requests natuurlijk netjes naar %23. Maar wat blijkt: IIS beschouwt ook het gedeelte na een %23 in een url als fragment! Dat is vreemd… maar vooral ook vervelend, want dat zorgt er voor dat onze routes niet aankomen. De oplossing van de ontwikkelaar die hier mee bezig geweest is, was het vervangen van iedere # door een ander teken om dit aan de server-kant vervolgens weer terug te zetten. Hiervoor moest hij natuurlijk een teken hebben dan verder nooit gebruikt wordt. In al zijn wijsheid koos hij hiervoor unicode character U+1F4A9, oftwel Pile of Poo. Die kende ik nog niet, weer wat geleerd.
Aparte keuze, maar eerlijk is eerlijk: het zal ongetwijfeld nooit in id’s voorkomen. Toch denk ik dat er binnenkort óf een pull request richting Nancy gaat, óf er een aanpassing in deze workaround komt 😉

Tim!

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *