Variables globales

Les variables globales, say le mal. Plus il y a de variables globales, plus il y a de risques de collisions et d'écrasement. Qu'est-ce qu'une variable globale ? Une variable peut être déclarée de plusieurs façons. Par défaut, elle sera toujours déclarée globalement. C'est à dire rattachée à l'objet window. Je peux rattacher une variable en tant qu'attribut d'un autre objet (document.body par exemple, body est une variable de document, document est une variable de window) ou l'enfermer dans le contexte d'une fonction. Exemple :

  1. var test1 = 1;
  2. (function(){
  3. 	var test2 = 2;
  4. 	alert(test1);
  5. 	alert(test2);
  6. })();
  7. alert(test2);

Que va-t-il se passer ? Un dialogue affichant "1" (test1 est accessible à la fonction, car globale), puis "2" (test2 est accessible à la fonction car déclarée dans la fonction), puis erreur : test2 is not defined. La variable test2 a été déclarée dans la fonction, elle n'est donc accessible que dans cette fonction.

Pourquoi est-ce mal de déclarer des variables globales ? Simplement, parce qu'on ne maîtrise plus ses données. Imaginons que je charge une librairie qui a déclaré la fonction window.getKikooLol(). Puis je charge un autre script d'un de mes anciens projets qui a lui aussi une fonction window.getKikooLol(). Et bien l'une des deux va être écrasée. Sachant qu'elles ne faisaient pas la même chose, je vais avoir une fonction qui ne fera pas exactement ce que j'attends d'elle.

Alors, maintenant que vous savez pourquoi les globales say le mal, voyons voir combien de globales nous imposent les libs les plus célèbres :

  • Scriptaculous : 23 Afficher détails
  • Mootools : 85 Afficher détails
  • jQuery : 3 Afficher détails
  • YUI : 1 Afficher détails

Vous l'aurez compris, Scriptaculous et Mootools puent du cul.

Fonction $

Un autre gros reproche que je fais aux librairies les plus communes est la variable $. En fait ça rejoint un peu le paragraphe précédent avec l'écrasement des variables avec un truc en plus dont tout le monde se fout mais qui fait bien dans un article technique. La spécification de l'ECMA dit que le signe dollar est destiné à être utilisé uniquement dans le code généré mécaniquement. Alors, on sait pas trop ce que ça veut dire, mais il n'empêche que c'est interdit d'utiliser le signe dollar !

À coté de ça, on retrouve des arguments plus classique mais non moins pertinents tels que ceux déjà proposés plus haut : l'écrasement des variables. À la base, c'est Prototype (la première librairie ajax historiquement) qui a introduit cette variable $. L'idée a été reprise par toutes les autres : scriptaculous, ms atlas, mootools, jquery… mais pas YUI ! Le problème qui va se poser, c'est que si vous devez utiliser plusieurs librairies dans un projet, c'est impossible car la fonction $ sera écrasée.

J'ai été confronté au problème lors du développement de Pixearch. J'y ai intégré un mode d'affichage de type coverflow. Ayant la flemme de développer cet affichage, j'en ai pris un libre de droit. J'avais le choix entre un sublime écrit avec Mootools, un moins joli écrit avec scriptaculous, et un moche autonome. Les deux premiers ont du passer à la trappe car Dotclear inclus d'office jQuery qui définit donc sa propre variable $. Scriptaculous et Mootools surchargent donc celle-ci et font péter tout les scripts basés sur cette fonction $.

C'est pour ça que Pixearch a un mode coverflow moche !

Conclusion

YUI est très jolie.