Développement

Quelques notes pour répondre à des problématiques rencontrées au travail.

Organisation du code Javascript

« Le Javascript, c’est le bazar ! »

Non, c’est multithread.

C’est à dire qu’en Javascript, différentes portions de code peuvent s’exécuter simultanément. Voici un exemple des actions qu’on réaliserait côté client, avec Javascript :

  • dérouler le menu du site
  • et dans le même temps, passer à la deuxième diapo du carrousel

Le code reste procédural, mais a de quoi désarçonner le plus barbu des développeurs qui n’aurait vu que du PHP. En effet, dans la plupart des langages serveur (notamment PHP), les actions s’exécutent les unes à la suite des autres. Par exemple :

  • récupération des données
  • puis, génération d’un fichier PDF
  • et enfin, envoi du fichier par e-mail

La logique du développement front end (client) n’est pas la même que celle du back end (serveur) !

En Javascript, on commence souvent par créer un document ready, qu’on complète petit à petit par différents écouteurs.

Imaginons un bouton :

<button id="button">Je suis un bouton</button>

Ajoutons-lui un écouteur au click :

$(document).ready(function() {

    $('#button').click(function(){
        console.log("Click!");
    });

});

Avec le temps et les développeurs qui se succèdent sur le projet, les écouteurs se multiplient et peuvent finir par se mordre la queue. Il n’est pas rare de se retrouver avec plusieurs écouteurs qui sont lancés en même temps ; c’est là qu’on se rend compte que le Javascript est mutlithread.

Votre écouteur est noyé dans une masse de code. Un collègue ajoute un autre écouteur à sa sauce, sans avoir remarqué le votre.

$(document).ready(function() {

    // Beaucoup de code là...

    $('#button').click(function(){
        console.log("Click!");
    });

    // Beaucoup de code ici...

    $('button').on('click', function(){
        console.log("Click triggered");
    });
});

Maintenant, si je clique sur le bouton, ma console va afficher simultanément Click! et Click triggered. Imaginez sur des actions plus complexes, on peut avoir beaucoup de mal à identifier quelles portions de code sont exécutées, et à quel moment. Pourtant, ce n’est pas compliqué lorsque les choses sont faites correctement dès le départ.

Le document ready doit être vu comme la fonction principale de votre site, celle qui est déclenchée à chaque chargement de page. Pour les barbus, c’est un peu le main, le point d’entrée du programme. Facile !

Pour garder le contrôle sur les portions de code déclenchées au cours de la navigation, il faut essayer de garder le document ready le plus clair possible. Dans l’idéal, il ne contiendra que des écouteurs simples, qui ne font pas plus d’une quinzaine de lignes. C’est un objectif que vous ne devez jamais perdre de vue.

« Bon, je fais des fonctions alors ? »

Tout à fait !

Il faut compartimenter. Une fonction par fonctionnalité : la nature est bien faite.

« Mon code n’est utilisé qu’ici, il n’est pas générique. Je fais quand même une fonction ? »

S’il est un peu long, oui.

Cela permet d’externaliser le gros code et garder un document ready concis. Souvenez-vous, c’est cet objectif qui prime sur les autres. C’est la seule façon d’assurer la maintenabilité du code.

« Super, avec toutes ces fonctions mon fichier fait 2000 lignes… »

C’est vrai, mais il est lisible.

Pour améliorer la structuration du code, il est possible de rajouter un niveau hiérarchique : le fichier. On peut ainsi compartimenter chaque fonctionnalité dans un fichier dédié :

  • forms.js
  • products.js
  • animations.js

Si vous utilisez un CMS, il conviendra de mettre en place la compilation des assets (fichiers CSS/JS) pour ne servir qu’un seul fichier au navigateur, de façon à limiter le nombre de requêtes nécessaires au chargement du site.

Publié le 10/10/2014
dans la catégorie Développement.
Dernière mise à jour le 16/10/2014.

Tags : javascript

Commentaires

Poster un commentaire

Votre adresse e-mail ne sera pas affichée sur le site.