JS (5/5) — Asynchronicité
Last updated
Was this helpful?
Last updated
Was this helpful?
Comprendre le principe de base de l'asynchronicité
Modéliser l'orchestration des entités
Identifier les différents éléments du langage concernés
Vérifier l'exactitude d'un formulaire d'après votre serveur
Modifier des éléments de la page en fonction d'une réponse serveur
Gérer un JSON
Le concept d'asynchronicité s'oppose à la syncrhonicité des opérations effectuées dans un code source. L'éxecution des instructions devient non linéaire dans le temps et donc, certains instructions sont non blocantes : elles s'éxecutent "à côté" le temps qu'elles finissent leur tâche.
Attention ! L'asynchronicité ne sous-entends pas multi-coeur, ni multi-threading.
Une fonction de callback est une fonction (généralement anonyme) qui est passée à une autre fonction qui va l'éxecuter ultérieurement. Cette technique est largement utilisée dans l'asynchronicité.
Exemple de callback avec une fonction du langage JavaScript
Exemple de callback "custom"
Vous devez avoir remarqué depuis le temps l'utilisation des fonctions anonymes en callback (notamment dans les listener d'évènements) (i.e. addEventListener("click", function(){})
). Vous pouvez aussi utiliser des arrows/arrows functions/fonction fléchées qui fonctionnent PRESQUE de la même manière. Leurs deux principales particularités sont :
Une modification du contexte pour l'operateur d'introspection (i.e. this
)
Une simplification du mécanisme de cascade de callback (notamment pour les promesses.)
Exemple pour l'opérateur d'introspection :
Les promesses sont assez similaires aux callbacks. Ce sont toutefois des objets retournés auquels est attaché des fonctions de callbacks, plutôt que de passer des callbakcs à une fonction. Les promesses sont conçues pour spécifiquement simplifier la gestion des opérations asynchrone, comme communiqué avec le serveur. Elles permettent notamment :
De rendre le chaînage de plusieurs opérations asynchrones beaucoup plus simple et plus lisible (cela inclus le passage du résultat d'une promesse à une autre)
D'assurer la cohérence dans la queue évènementiel
D'avoir une meilleur gestion d'erreurs
Eviter les attaques par inversion de contrôle
Explication détaillée sur les promesses.
Imaginons que votre serveur -- pour accélerer le traitement et réduire le coût -- ne construise le catalogue des (millions de) média qu'avec le titre et le lien URL de l'image du film au moment de servir la page à un utilisateur. Au moment où l'utilisateur passera la souris au dessus d'un média, ce dernier vous enverra une requête à votre serveur pour récupérer les informations supplémentaires et les afficher.
Cela s'appele faire une requête asynchrone : échanger avec votre serveur (et ici récupérer des données supplémentaires) sans changer de page (i.e. sans se faire resservir une nouvelle page HTML).
Pour faire cela, il existe deux approches :
L'objet XMLHttpRequest (la méthode "old school")
La méthode fetch
du mixin WindowOrWorkerGlobalScope
(nouvelle approche)
La méthode fetch
à l'avantage d'être concise et plus facilement lisible grâce à l'utilisation de promesses. Par exemple, ci dessous le code qui interroge le répertoire CDAW sur GitHub pour récupérer d'abord les commits, puis va chercher de nouveau des informations avec un deuxième fetch pour récupérer les informations de la personne qui a réalisé le second commit du repo.
Généralement, un serveur offre une API pour favoriser la communication et l'accès aux informations via une approche asynchrone (e.g. API GitHub). Une API n'est ni plus ni moins que des routes spécifiques dédiées à gérer ces requêtes asynchrones. N'hésitez pas à faire la votre.
JSON est un format de données qui se présente sous la forme d'une chaîne de caractères. Il a la particularité de pouvoir facilement représenter les objets JavaScripts (vous pouvez même stocker des tableaux !). Si vous utilisez une API, ou communiquez de manière asynchrone avec votre serveur, il y a de forte chance que votre serveur vous communique des informations dans ce format. Un exemple de JSON (qui vient d'ici) :
Néanmoins, vous ne pouvez pas utiliser du JSON directement en JS, vous devez le parser pour le faire correspondre à des objets JavaScript. Heureusement pour vous, le langage possède déjà une fonction toute prête appelée JSON.parse
. Son prototype et utilisation est le suivant :
Un reviver vous permet d'appliquer un comportement spécifique lorsqu'un couple clef/valeur JSON est lue. Par exemple pour le champ date
de l'exemple précédent.
https://developer.mozilla.org/fr/docs/Learn/JavaScript/Objects/JSON
Supposons que vous voulez communiquer à votre serveur de manière asynchrone la création d'un nouveau média :
Linéariser cet objet en JSON.
Supposons que vous voulez communiquer à votre serveur de manière asynchrone la création d'un nouveau média auquel vous associez un score d'après le retour de certains utilisateurs :
Linéariser cet objet en JSON
Comment faire pour régler le problèle ?
Supposons que lors d'une requête asynchrone, votre serveur vous réponde avec ce JSON là :
Effectuer l'analyse syntaxique (parser) du JSON reçu.
Supposons maintenant que lors d'une requête asynchrone, votre serveur vous réponde avec ce JSON là :
Effectuer l'analyse syntaxique du JSON reçu
Une fois l'objet créer, exécuter monObjetCréer.date.getDate()
; que constatez-vous ?
Utiliser un reviver pour traiter correctement la date !
Imaginons que votre serveur vous ait servi cette page de catalogue de média :
Et que votre serveur vous propose une API pour récupérer des informations sur les médias. L'API est : https://api.jikan.moe/v3/anime/
, et l'identifiant de votre média est dans le data-attribute
appelé data-anime
. Pour récupérer les informations d'un média avec, disons, le data-attribute data-anime=5
vous requêterez donc https://api.jikan.moe/v3/anime/5
.
Vous pouvez accéder aux data-attributes via monElement.dataset.leNomApresData
.
Faîtes une requête et afficher le contenu de https://api.jikan.moe/v3/anime/10
, imprégnez vous des champs accessibles ;
Lorsque vous cliquez sur votre média, récupérez les informations relatives qui sont liées, et enrichissez le champ description ;
Lorsque vous survolez votre média, le trailer associé doit se lancer. Vous utiliserez une balise iframe
;
Maintenant, on ne veut plus faire d'autres requête au serveur si on a déjà demandé au serveur les informations pour un media spécifique. Par exemple, si on clique sur le media, et ensuite qu'on le survole, rien ne sera demandé au serveur dans ce deuxième évènement et le client réutilisera les informations stockées.
Faîtes la même chose, mais en utilisant XMLHttpRequest
à la place de fetch
!