Différences

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

--- javascript:async [04/04/2013 16:23] – 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 =====
-Généralités
-  * http://www.w3.org/TR/DOM-Level-3-Events/#event-flow pour comprendre le "dispatch" de l'evt et ses 3 phases capture/target/bubble
-  * http://www.yoyodesign.org/doc/w3c/dom2-events/events.html (en fr)
-  * http://www.quirksmode.org/dom/events/index.html table de compatibilité des evts
-  * https://developer.mozilla.org/en-US/docs/DOM/Event/CustomEvent
-  * liste de tous les [[https://developer.mozilla.org/en-US/docs/DOM/Mozilla_event_reference|types]] dispo suivant le dom level
-Un ex simple de création d'evts perso en DOM2
-  * http://www.kaizou.org/2010/03/generating-custom-javascript-events/
-  * Ex de addEventListener en [[https://developer.mozilla.org/fr/docs/DOM/element.addEventListener|VF] mais + détaillé en [[https://developer.mozilla.org/en-US/docs/DOM/EventTarget.addEventListener|en] (compat IE9 only, attachEvent avant)
-===== 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
-  *  ajouter un listener qui capture la propagation, fait un traitement, arrête d'écouter l'evt puis relance l'evt. Ils seront appellés dans l'ordre où ils se sont enregistrés mais l'arrêt de la propagation ne marche pas sur les écouteurs de la même cible.
-  * se créer un gestionnaire de pile unique qui gère l'empilement et le dépilement, une fct globale (pour être unique) avec une pile privée, pour être sûr que personne ne peut faire qqchose entre le test de la pile et sa modification (qui dépend du test). Ex avec http://code.stephenmorley.org/javascript/queues/
-Pour implémenter une file d'attente (queue), un singleton pourrait être bien pratique
-  * http://www.tassedecafe.org/1023-implementer-design-pattern-singleton-javascript.html
-  * http://code18.blogspot.fr/2009/07/creer-un-singleton-en-javascript.html
-  * http://stackoverflow.com/questions/1635800/javascript-best-singleton-pattern