Différences

Ci-dessous, les différences entre deux révisions de la page.

--- javascript:async [04/04/2013 15:12] – créée daniel
+++ javascript:async [13/03/2025 14:48] (Version actuelle) – supprimée daniel
@@ Ligne 1: / Ligne 1: @@
-====== 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.
-<code javascript>
-// 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...
-<code>
-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 =====
-===== TodoList =====
-Dans certains cas, on veut traiter des actions séquentiellement (car chacune modifie un objet global dont elle utilise l'état par ex), le plus simple est de les empiler, via un gestionnaire de pile unique qui gère l'empilement et le dépilement, pour être sûr que personne ne peut faire qqchose entre le test de la pile et sa modification (qui dépend du test).