Promesses en JavaScript : une introduction

L’article suivant couvre une brève introduction au concept de promesses. Les promesses sont nouvelles pour JavaScript (introduites dans ES6) et souvent mal comprises. Le concept est essentiellement une réorientation d’idées familières dans une image de marque sophistiquée.

Les promesses sont un moyen d’exécuter du code asynchrone. Parce que JavaScript est un langage à thread unique, des outils doivent être créés pour que cela se produise car cela ne se produit pas de manière native.

Je vais passer en revue deux exemples détaillés de ce à quoi une promesse peut ressembler, comment .alors Les déclarations sont enchaînées, et ce qui provoque une .attraper déclencher et où il peut être déclenché. Le dernier sujet sera l’ordre d’exécution lorsque les promesses sont exécutées dans plusieurs lignes de code et à quoi ressemble une résolution de promesse réussie par rapport à ce à quoi ressemble une promesse échouée à partir d’une API externe.

En quoi le code asynchrone est différent

Le code synchrone est facile à comprendre. C’est un peu comme l’écriture elle-même.

J’écris cette ligne en premier. Et maintenant, c’est lu en premier.

Oups, nous sommes ici maintenant. Cette ligne est en cours d’exécution.

Etc.

Et ainsi de suite.

Mais avec le code asynchrone, les fichiers de code ressemblent davantage à des recettes. Lisez un peu, mesurez, hachez et ajoutez plus d’ail… Il y a des instructions, des actions et à travers le texte, les lignes peuvent commencer comme lues dans l’ordre, mais différents processus prennent plus de temps que d’autres. Cela dit, à aucun moment le processus de demande ou de dîner ne s’arrête parce qu’une réponse du serveur ou une brochette de crevettes prend plus de temps que prévu.

L’anatomie d’une promesse

Une promesse est un objet qui représente l’accomplissement éventuel d’une opération asynchrone. Il existe sous trois états :

  • En attente: c’est le point de départ. La “promesse” qu’à un moment donné, il y aura une réponse à cette question même si l’application continue à exécuter du code plus bas dans le fichier.
  • Réalisé/résolu: La promesse a été résolue avec succès. La condition remplie était vraie ou des données ont été renvoyées.
  • Échec/rejeté: Le résultat de la promesse si une erreur s’est produite lors de l’exécution de la promesse.

Aussi, connaissez ces méthodes :

  • .alors: La méthode JavaScript utilisée pour gérer une promesse réussie.
  • .attraper: Comment les erreurs sont détectées.

Une nouvelle classe de promesse est créée avec deux paramètres, résoudre et rejeter. Dans cet exemple très basique, il y a une valeur. Si la valeur de la chaîne est correcte, elle résoudra “correct” et si elle est incorrecte, elle rejettera “error”. Simple.

Résolvons la promesse.

Et voici à quoi cela ressemble si l’instruction conditionnelle est fausse.

C’est incroyablement basique et ce n’est pas un cas d’utilisation probable pour les promesses.

Éviter l’enfer des rappels

L’enfer du rappel : un terme ambigu mais descriptif. Trop de rappels. Nidification profonde. La fonctionnalité n’est généralement pas compromise, mais la lisibilité est un cauchemar et cela a tendance à compromettre la fonctionnalité, en particulier lorsqu’il s’agit de mises à jour de code, en particulier lorsque des ingénieurs supplémentaires y travaillent.

L’image ci-dessus est le début de l’enfer des rappels (extrait de mon article 3 types de programmation asynchrone). Si vous google callback hell, il y a beaucoup d’images bien pires qui ne peuvent pas être incluses dans cet article pour des raisons d’écriture de copie.

L’exemple ci-dessus s’appuie sur le premier exemple. Cette fonction prend dans une structure de données et s’il s’agit en fait d’un tableau, elle résout la somme de ses éléments, sinon rejette la promesse. La réponse est console.log 29.

Que se passe-t-il si une chaîne est transmise ?

En passant en {e} renverra l’erreur en tant qu’objet d’erreur, ce qui est utile dans des cas d’utilisation plus avancés.

Parfait, ça marche.

Que se passe-t-il si nous voulons prendre la somme, trouver le reste après qu’il soit divisé par deux puis soustraire 50 ? .puis Il peut être enchaîné et il ressemblera à ceci. Continuez à transmettre des données de l’un à l’autre et nous avançons.

Et les journaux de la console ressemblent à ceci :

Mais s’il y a une erreur, telle qu’une variable indéfinie soustraite par l’une de ces valeurs, l’objet d’erreur s’affichera.

Excellent exemple, mais comme le premier, pas de code asynchrone non plus.

Exemple asynchrone — Requêtes HTTP

Pour cet exemple, j’utilise l’API Star Wars. Voici le code :

Les journaux de la console ressemblent à ceci :

Mais si le code change pour devenir légèrement retardé de 1/4 de seconde plutôt que retardé de 1 seconde :

Le fichier console.logs ressemblera à ceci :

Les journaux de la console ressemblent à ceci :

Et voici un exemple de chaînage de promesses lors de la réception de données dans la requête API.

Si une requête a été faite à une mauvaise API par exemple :

Ensuite, vous pouvez soit console.log un message spécifique ou l’intégralité de l’objet d’erreur. L’objet d’erreur dans ce cas ressemble à ceci :

Apprentissage supplémentaire

C’était une introduction incroyablement brève et basique aux promesses. L’apprentissage devient assez lourd après cet arrêt initial. Pour une plongée plus profonde dans le matériau, c’est un bon endroit pour regarder. Codingame est un site où vous pouvez commencer à travailler avec du code asynchrone et promet une expérience d’apprentissage plus pratique.

Groupe Créé avec Sketch.

Leave a Comment

Your email address will not be published. Required fields are marked *