Table des matières

Gestion asynchrone

JS est asynchrone, c'est ce qui fait sont intérêt mais qui est aussi souvent source de bugs, difficile à résoudre car ils peuvent être rares et sembler totalement aléatoire (suivant local / distant, la qualité du réseau, la présence de certains scripts en cache et pas d'autres, la déclaration de tel truc avant chargement ou après, etc…).

L'exemple typique, panneau dans lequel tombe tout débutant mais dès qu'il est un tout petit peu déguisé même un dev chevronné se fait avoir de temps en temps.

// appel d'une fct dont un argument est une fct anonyme de rappel
maFct(arg1, function(){
  // code 1
  // code 1bis
});
// code 2, qui sera probablement exécuté avant code 1
// code 2bis, dont on ne peut absolument pas savoir s'il sera exécuté avant ou après 1bis
// c'est souvent ici que se cache les bugs, le truc qui passe toujours avant, sauf parfois...

C'est souvent lié aux pb de chargement, mais pas seulement.

Il faut donc “penser évenementiel” et plus du tout procédural, mais quand on a qq années de pratique procédurale (même en js), c'est pas si simple.

C'est la logique du “prévenez moi quand ce sera mon tour”, qu'il faut systématiser à toutes les actions qui peuvent dépendre de l'état de l'application. Par ex, pour changer un picto sous une image quand elle est chargée, pas besoin de se préoccuper de ce qui se passe dans le reste de la page, mais à condition d'être sûr que le reste ne peut pas perturber notre action (oups, ce “for i…” avec un i global…), ce qui impose donc de protéger absolument toutes nos variables, la plupart du temps dans des fcts anonymes parce que c'est le plus simple.

Gestion d'événements

Généralités

Un ex simple de création d'evts perso en DOM2

TodoList

Dans certains cas, on veut traiter des actions séquentiellement (car chacune modifie un objet global dont elle utilise l'état par ex), on peut faire

Pour implémenter une file d'attente (queue), un singleton pourrait être bien pratique