Transcript for:
Comprendre les Promesses en JavaScript

bienvenue dans ce nouveau chapitre nous allons parler des promesses qui sont une notion assez importante qui a créé à la synchrone que l'on a vu dans le chapitre précédent on l'a vu le principal problème avec la synchrone c'est qu'on se retrouve très souvent à avoir des Call backs en école bagues en école back et écrire du code comme ça ce n'est pas pérenne pour pour le long terme donc heureusement dans le JavaScript on a des objets qui vont permettre justement de représenter ce côté à synchrone et de pouvoir travailler plus facilement avec et ses objets ce sont les promesses alors pour les utiliser il va falloir créer une nouvelle instance de l'objet promise donc on fait un constat on va l'appeler ici P et on fera mieux promise au niveau de son constructeur les promesses attendent un paramètre qui sera une fonction qui aura deux paramètres un premier qui s'appellera resolve et un second qui s'appelera reggate en général on utilisera ces noms pour ces deux paramètres là resolve sera une fonction que l'on appellera pour dire que notre promesse a été résolue donc comme dans la vraie vie si on respecte notre promesse on dira voilà là à ce moment-là je viens de la respecter et donc j'utiliserai resolve si jamais on réalise que la promesse on ne peut pas la tenir parce que c'est un truc qui est imposable mais dans ce cas là on utilisera la méthode reeject donc nous ici on va s'imaginer une promesse qui se résout tout de suite et on va utiliser la méthode resolve et en lui passera une valeur et on peut même lui en passer plusieurs donc là on a une promesse qui s'autorise si vous avez besoin de plus d'informations sur les promesses comme d'habitude il nous faudra pas hésiter à faire un petit tour sur la documentation et surtout sur la partie référence pour voir les différentes méthodes et on voit qu'il y a pas mal de méthodes qui sont directement disponibles sur l'objet promise mais nous ce qui va nous intéresser c'est ce qui a trait au prototype alors déjà on regarder qu'est-ce qui qu'est-ce qui nous affiche en console donc on va faire une console point loc de P et on va regarder notre console donc on voit qu'on nous dit c'est un objet promise et le navigateur il a une petite manière particulière de nous expliquer un petit peu à quoi ressemble cette promesse il nous met qu'elle a été full field avec la valeur 4 si je sais de faire la même promesse que je rejette mais dans ce cas là on me dit que c'est une promesse qui était rejetée donc c'est une promesse qui n'a pas été respectée et elle a été rejetée avec avec la valeur 4 alors maintenant c'est bien mais moi dans la suite de mon script j'aimerais bien justement savoir est-ce que la promesse a été résolue ou non donc pour cela on a deux méthodes que l'on peut utiliser sur les promesses on a une première méthode veine cette méthode prend en paramètre un callback que l'on appellera et ce callback prendra en paramètre les valeurs renvoyées lors de la résolution de la promesse donc nous typiquement ici on aurait un nombre et par exemple je pourrais lui dire bah lorsque cette promesse a été résolue j'aimerais bien que tu m'affiche le nombre et ensuite de la valeur de ce nombre là et là ça va me donner la valeur 4 si jamais une promesse échoue on peut capturer cet échec en utilisant la méthode catch vous remarquez que ça ressemble un petit peu au travail catch c'est le même principe une promesse peut ne pas être respectée et dans ce cas-là on va pouvoir capturer cette échec là et là on va faire une console point log et on va faire échec et on va regarder à quoi ça ressemble donc ici je vais utiliser ridgeject et on va voir que c'est bien catch qui est appelé avec cette valeur là alors si on regarde le retour de ce p.4 ou même du p.ven on va voir que le retour lui-même de ces méthodes là c'est une promesse donc ce qu'il est possible de faire c'est de faire les choses de la manière suivante on va lui dire si la promesse a bien été résolue on aura un nombre que l'on va afficher mais par contre si jamais la promesse échoue dans ce cas là on aura une erreur par exemple et on pourra faire une console point log erreur et utiliser ensuite l'erreur donc on peut enchaîner les choses comme ça moi ici il me dit qu'il ne connaît pas eux effectivement il faut mettre un N donc la promesse fonctionne c'est le vin qui est appelé la promesse échoue c'est le catch qui est appelé alors là en l'état vous dites ouais mais ça a pas l'air de résoudre le problème des callbacks parce que finalement tu as un call back le principal avantage c'est que ce que l'on fait dans le vein et aussi ce que l'on fait dans le catch peut continuer à être utilisé imaginons à ce niveau là je me décide de retourner 5 donc en fait je lui dis quand la promesse est résolue je veux exécuter ce code là qui retourne 5 donc ça ça nous donne encore une fois une promesse et on peut continuer à enchaîner les choses par exemple on peut lui dire bon ben quand cette nouvelle promesse est résolue j'aimerais bien faire encore une fois une console point log on va mettre le nombre 2 pour pouvoir faire la différence et ensuite on mettra la valeur de ce nombre là et tout ça on le cache donc si je sauvegarde on voit que ça va me donner ici une erreur parce que la promesse a été échouée on fait qu'on a un reggaject mais si je la résolve on va voir les deux consoles point log donc l'avantage c'est que c'est beaucoup plus facile d'enchaîner les choses et en général on va utiliser une syntaxe voilà hop on ferme on va mettre en forme de cette manière là les choses les unes à la suite des autres c'est un petit peu plus facile de comprendre la logique donc là lorsqu'il y a une résolution ça retourne quelque chose et vu que ça retourne quelque chose ça renvoie une nouvelle promesse qu'on peut aussi écouter pour voir si elle est résolue si je ne mets rien à ce niveau là le second veine sera quand même appelé mais avec la valeur indie find vu que la fonction ne retourne rien elle retourne à defight l'intérêt aussi c'est que ici je peux me dire ah bah là il y a un petit problème par exemple j'avais pas prévu ce coup là et je vais mettre ici échec si je fais ça on va voir qu'il y a deux consoles points lo qui vont être activées il y a celui-ci vu que notre promesse a bien été résolue mais vu que dans le callback de la première résolution on a une erreur il va considérer que cette nouvelle promesse qui a un résulte est en erreur et du coup on peut cacher cette erreur là donc on aura la fois ce code là et ce code là qui va être exécuté et de la même manière si on continue à être encore plus plus fou on peut ici lui dire en fait il faut que tu retournes 2 et dans ce cas là le résultat du catch c'est encore une promesse que je peux aussi capturer lui dire bon ben si ça ça a bien marché je veux encore faire une console point log et dans ce cas là ça nous donne RA2 en console parce que le retour du catch nous renvoie une promesse qui est résolue de cette manière là donc cette manière d'écrire les choses me permet en fait d'avoir toujours des callbacks ça c'est toujours un problème mais on va voir qu'il y a une syntaxe qui permet de remédier à ce problème là mais nous permet surtout de représenter du code séquentiel beaucoup plus facilement la de la même manière lorsque vous faites un retour ça peut être directement une valeur et dans ce cas là cette valeur sera résolue directement et on appellera le vin suivant soit ça peut aussi être une nouvelle promesse mais on va faire un exemple juste après avec les timers une dernière chose on a une troisième méthode que l'on peut utiliser sur les promesses qui est finalement quelque chose qui va être exécuté quoi qu'il arrive c'est à dire que la promesse échoue que la promesse réussisse ça on l'affiche tout le temps donc là on voit que ça va nous afficher à AA si on n'avait pas le VN et qu'on laissait le catch agir le AAA serait toujours affiché donc le finali va être exécuté quoi qu'il arrive que la promesse soit résolue ou non donc tout de suite on met le resolve et le rejet et hop on n'oublie pas la petite flèche plutôt que de directement mettre un resolve de 4 on va utiliser le 7e on va lui dire d'exécuter une fonction et dans cette fonction fera un résolve et on va lui demander d'attendre pendant une durée déterminée cette durée en la passera en paramètre de notre fonction wait l'histoire d'avoir un paramètre dans le résolve je vais lui dire de résolve avec la durée de notre timer et on va faire la même chose pour une promesse qui échoue donc à ce niveau là on va créer une autre fonction qu'on va appeler wait and fail et elle elle fera la même chose sauf qu'au lieu de resolveject donc si maintenant je reteste ma promesse je peux lui dire à ce niveau là hop j'ai envie que tu fasses un wait je veux attendre pendant deux secondes et ensuite je veux que tu fasses un console point lock donc on peut directement lui passer console point log il sera appelé avec les bons paramètres si on regarde on va attendre ici 2 secondes et au bout de 2 secondes on va bien avoir le 2000 qui s'affiche l'avantage c'est que je peux lui dire en fait je vais appeler une fonction comme ceci hop on va mettre ici j'ai attendu attend de seconde et après on peut lui retourner une nouvelle promesse et on va lui dire j'aimerais bien que tu attendes une seconde et dans ce cas là le veine que l'on met derrière il ne sera appelé qu'au bout de une seconde après les deux secondes précédentes et là on mettra la tente de une seconde ici si à ce niveau là on faisait un return weight and fail après il faudra le capturer et on pourra le capturer grâce à un cache et vous pouvez enchaîner les choses au fur et à mesure on va s'arrêter juste à deux promesses consécutives c'est juste pour vous expliquer le principe mais vous voyez qu'au bout de deux secondes on a le attendre de 2 secondes et le attend de une seconde qui s'affiche donc cette syntaxe là permet de faire quelque chose en séquence un peu plus simplement que le système de callback l on a qu'un seul niveau finalement de call back et on voit que lorsqu'on en atteint la résolution d'une promesse on peut retourner une nouvelle promesse et le résultat de tout ça mais ça redonne une nouvelle promesse qui attendra la fin de cette promesse là et pour être juste sur qu'on soit hop tous sur la même longueur d'onde si je fais ici un return wait and fail vous allez voir que au bout de 2 secondes on va mettre un attente de 2 secondes et là on va me dire un coq in promis alors ça c'est une erreur qui veut dire que on a une promesse qui échoue et cette promesse on n'a pas géré de catch avec donc c'est exactement ce qui se passe ici on a effectivement une promesse que l'on attendait même si de toute façon je retire ça on aurait la même erreur donc quand une promesse échoue le navigateur lui va considérer que la l'erreur n'a pas été capturée et que ce n'est pas une bonne chose c'est une erreur qui peut être renvoyée ou non suivant les environnements donc la typiquement on pourrait faire un catch et à l'intérieur on met une fonction qui fait rien renverrait nul par exemple dans ce cas là notre promesse va bien capturer l'erreur et on voit qu'on a plus mais ce catch est bien appelé soit parce que directement cette promesse serait rejetée soit parce que le résultat du retour de cette fonction-là serait rejeté aussi c'est à dire que si ici je fais un white and fail directement ce catch va être appelé instantanément vu que c'est celle-ci qui échoue donc il faut bien comprendre le principe du chaînage pour ça que j'insiste un petit peu sur ce point là parce que c'est un élément assez important dans l'utilisation des promesses alors maintenant on va parler d'un élément de syntaxe qui va nous permettre avec les promesses de travailler beaucoup plus simplement le système de veine et de catch et de callback c'est pas forcément tout très pratique dans certaines situations alors vous pouvez déclarer une fonction comme asynchrone en utilisant le mot clé usink ensuite vous nommez votre fonction de manière classique donc nous on va l'appeler main comme la fonction principale donc ça marche de cette manière là mais ça marche aussi si vous créez la fonction avec le système de constante vous pouvez mettre think et ensuite mettre votre fonction fléchées ou mettre votre fonction avec le mot clé fonction ça marche dans toutes les situations donc toutes les fonctions que l'on a vu peuvent être rendues à synchrone lorsqu'une fonction est déclarée de manière assez grande même si elle retourne à un résultat directement là on est d'accord que ce code techniquement il est pas synchrone si j'appelle cette fonction là et que je regarde son résultat on va voir que ça va me dire que c'est une promesse c'est une promesse qui est remplie vu qu'on retourne une valeur et qui renvoie 4 si à l'intérieur de cette fonction on fait un Frau et qu'on envoie une erreur mais dans ce cas-là ça renverra une promesse qui est rejetée avec l'erreur en question donc ça change la manière de travailler finalement avec les promesses mais ce qui est super intéressant c'est qu'on peut utiliser le mot clé ewate lorsqu'on utilise une promesse dans une fonction asynchrone imaginons j'ai envie de faire un petit peu ce que j'avais fait tout à l'heure atteindre de seconde et afficher une console point lock parce que je peux faire c'est utiliser le mot clé awate et ensuite il faudra mettre une promesse dont on atteint la résolution donc nous on va générer cette promesse en utilisant notre fonction wait et après je peux faire un console point log et afficher par exemple bonjour si j'essaie maintenant d'exécuter cette fonction main qu'est-ce qui va se passer mais il va attendre les deux secondes parce que ça c'est une promesse et ce code là ne sera exécuté qu'après l'avantage c'est que cette syntaxe permet d'être beaucoup plus rapide si je veux lui dire ensuite à temps une seconde et refait un console point log derrière vous voyez c'est beaucoup plus facile à écrire et ça se lit de manière plus linéaire que le système de callback dans ce cas là il va attendre 2 secondes afficher bonjour puis une seconde plus tard afficher hello si par contre une promesse échoue si jamais on fait un weight and fail mais il faudra la capturer avec la syntaxe strikatch habituel donc par exemple ici il faudra faire un trail on pourra entourer tout notre code ici hop et lui dire bon bah il y a quelque chose qui s'est passé de manière incorrecte et on peut réagir en fonction par exemple ici on pourrait faire un console.log error si je sauvegarde on va voir que dans ce cas là la première va échouer et on arrive dans ce cas-là donc la syntaxe Wade est think permet encore une fois d'avoir quelque chose de à plat beaucoup plus simple à lire autre petit détail si votre promesse renvoie un résultat vous pouvez lui utiliser avec le White par exemple je peux faire un console point log lui dire attends de faire une attente de 2 secondes ça on avait vu que le weight ça nous renvoyait une promesse qui se résolvait avec la valeur de la durée ben dans ce cas là dans le console point lock je vais avoir la valeur de la durée ici 2000 mais je pourrais tout aussi bien le sauvegarder dans une variable par exemple on va l'appeler du reichen voilà j'attends la résolution de cette promesse pour que cette valeur soit définie et après je peux faire une console point log et afficher la durée donc on mettrait du Raichu enfin un dernier petit point c'est que si je décide plus tard de faire un retard de 5 là il faut bien comprendre que cette fonction-là elle renverra une promesse donc je pourrais tout à fait lui dire ici bon ben lorsque notre fonction main a fini de s'exécuter donc lorsque on a le 5 qui est renvoyé je veux faire quelque chose par exemple faire un console.log dans ce cas là il attendra que toutes ces promesses soient résolues et c'est comme la syntaxe de veine que l'on a écrit précédemment mais écrit finalement différemment donc le Think awate ne va pas apporter de nouvelles fonctionnalités il va surtout nous permettre de travailler plus simplement avec les promesses enfin un dernier petit détail sur le Think et le weight sur certains environnements vous pouvez utiliser ce que l'on appelle les tops level wait c'est à dire que vous pouvez lui dire par exemple là je veux attendre hop de seconde et au bout de 2 secondes de faire un console point de log de Hello donc là sur le navigateur on voit que tout de suite ça nous renvoie une erreur nous dit non le awake il ne peut être utilisé que dans les fonctions think ou dans le haut des modules mais ça c'est encore pour un autre chapitre mais donc là on ne peut pas écrire un awate comme ça ça sera réservé dans les fonctions asynchrones donc voilà pour ce petit détail alors maintenant on va parler de la possibilité de combiner les promesses ensemble et on va revenir sur la documentation donc on a déjà parlé du cash on a parlé du finalier du veine sur le prototype mais on voit qu'on a aussi d'autres d'autres choses alors d'abord les premiers points résolvent et promise.jete c'est très simple ça permet de renvoyer directement une promesse qui est résolue ça peut servir dans certaines situations ou des algorithmes attendent une promesse plutôt qu'un objet classique donc si je fais ici un promise point resolve et que je mets la valeur 2 automatiquement ça me donne une promesse qui est déjà résolue avec cette valeur là si je fais un promise point reeject et que je donne la valeur 2 ça nous donnera une promesse qui a échoué avec la valeur 2 voilà ça peut être utile mais concrètement ça correspondra à des situations assez spécifiques ensuite toutes les autres méthodes ont entrées justement à la combinaison des promesses alors on va commencer par le premier point hall c'est à mon sens peut-être le plus simple le premier point hall on va lui passer un premier paramètre unitérable donc considérez ça comme un tableau où on va lui donner différentes promesses et ensuite ce que ça va faire c'est que ça va nous renvoyer une nouvelle promesse qui aura comme résultat la résolution de toutes les promesses si une des promesses dans la liste échoue dans ce cas-là ça nous renverra le l'erreur de la promesse en question alors prenons un exemple concret ça nous parlera un petit peu plus on va faire un promise et on va lui passer de promesses une promesse qui va durer une seconde et une seconde promesse qui va durer deux secondes voilà et cette promesse on va regarder quand est-ce qu'elle est résolue et on va faire un console point log pour voir le résultat si je sauvegarde on voit que au niveau de ma console je n'ai rien et au bout de 2 secondes parce qu'il faut que les deux soient résolus dans ce cas là il va m'afficher un tableau alors on va essayer aussi de faire un catch et on va faire un console point log dans le cadre d'une erreur aussi si une de mes promesses échoue par exemple en imagine que la première échoue au bout de une seconde dans ce cas là la promesse va échouer directement et c'est ce catch qui va être appelé avec le résultat de la première promesse qui a échoué si c'était la seconde qui échoue et la première qui réussit ça ferait la même chose dans nos consoles ici on ne rentrerait dans le catch et j'aurai 2000 alors ensuite on a la méthode all settled donc c'est un petit peu le même principe que le hall sauf que ça ignore en fait les promesses qui vont échouer donc on va faire un hall settle voilà on va lui passer toujours de promesses qui réussissent et ici je regarde le retour je vais bien avoir mon tableau de taille 2 sauf que à l'intérieur je n'ai pas les valeurs mais j'ai des objets j'ai un objet qui contient le statut de la promesse fullfield ça veut dire que la promesse a bien réussi et la valeur si une de mes promesses venait à échouer donc on ferait un wait and fail ça serait toujours ce console point log qui serait appelé sauf que on aurait un objet avec une seconde promesse qui sera en mode rejective donc ça c'est intéressant si vous voulez lancer plusieurs opérations en même temps sans que une opération Vienne annuler le reste contrairement au hall où vous considérez que si une échoue votre votre système a échoué après on a aussi la méthode ENI donc la méthode ENI elle prend un paramètre encore une fois plusieurs promesses donc on va faire ici encore une fois uni on va lui donner deux promesses qui va bien fonctionner et pour différencier nos consoles on va mettre une console point error s'affiche les choses en rouge en console plutôt que le console point lock si je regarde dans ma console ça me donne 1000 donc ni nous nous donne le résultat de la première promesse qui est résolue si cette promesse venait à échouer par exemple on fait un wait and fail dans ce cas là ça va nous donner 2000 c'est à dire que ça nous donne le résultat de la première promesse qui n'est pas rejetée dans ce tableau là si les deux promesses venaient à échouer dans ce cas là toutes les promesses échouent et ils nous renverrai ici une erreur en nous donnant une agrégate erreur que l'on pourrait capturer grâce au catch enfin la dernière chose c'est le promise point rece c'est un petit peu comme le premier x point ENI si ce n'est que si la première promesse échoue il va considérer que c'est un échec donc il va regarder la première promesse qui arrive à terme que ce soit un échec ou une réussite et si c'est une réussite dans ce cas là il renverra une nouvelle promesse qui sera complétée dans le cas contraire il renverra une promesse qui est en échec si je fais ici un wait on obtient le même résultat que le ni c'est bien cette promesse là qui va être résolue en premier et si je fais un wait and fail là où le ENI attendait 2 secondes pour la résolution de celle-ci le Race va dire ah mais c'est celle-ci qui a été la plus rapide elle a été rejetée donc je rejette et c'est le catch donc voilà les différentes manières que l'on a de combiner les promesses je vous avouerai dans la vie de tous les jours c'est quand même des choses que vous avez besoin de faire assez rarement mais c'est le jour où vous avez besoin de le faire que c'est important donc c'est pour ça que c'est important de comprendre les différences entre ces différentes méthodes mais sachez qu'au jour le jour vous n'aurez pas forcément besoin de les utiliser toutes les deux secondes et vu que ces différentes méthodes renvoient une promesse si vous êtes dans un dans une fonction asynchrone mais vous pouvez lui dire au fait j'aimerais bien récupérer par exemple le résultat de la première promesse et faire un wait devant pour attendre la résolution ça permet aussi d'avoir une attaque qui est un peu plus simple plutôt que de combiner les veines mais ça il faut être dans une fonction asynchrone alors enfin un dernier petit point parce que je sais que certaines personnes ont eu des problèmes avec ça il faut bien comprendre que lorsque vous créez une promesse le code à l'intérieur de la promesse est tout de suite exécuté ce n'est pas lorsque vous faites un que il est exécuté si je recrée ma fonction qui permet d'atteindre de manière synchrone on va l'appeler waiting on lui passe la durée on crée une variable T qui est égale à la date du jour en milliseconde et en lui disant que la date du jour moins ST est inférieur à la durée que j'ai spécifié dans ce cas là je bloque mon script voilà donc imaginons que maintenant je me crée une promesse et cette promesse on va lui passer juste le resolve et on fera un console point log et l'eau et ensuite on lui dit de resolve avec la valeur 2 cette promesse on va le sauvegarder dans une variable on va faire constipé et ensuite on va lui dire attends de manière synchrone et attends 2 secondes alors là qu'est-ce qu'il me dit il me dit que P déjà utilisé ouais hop on avait utilisé en haut et ensuite je lui demande de faire un console.log les gens on pourrait se dire ben en fait la promesse là ce code là il va être exécuté de manière assez chronique mais pas du tout ce code que l'on a à l'intérieur va être exécuté tout de suite et si j'essaie de réactualiser ma page on voit bien qu'on a le hello qui s'affiche au tout de suite et les gens qui s'affichent tout de suite parce que j'ai oublié d'appeler la fonction date donc là on voit bien que ça tente 2 secondes avant d'afficher les gens cette fonction-là est directement appelée ce qui est asynchrone et ce qui va être appelé dans un second temps c'est ce que vous mettez dans le veine ce n'est pas ce que vous mettez dans cette fonction là donc ça c'est très important de bien comprendre ça si jamais vous avez du code bloquant à ce niveau là ce code bloquant va être tout de suite exécuté c'est un petit détail mais c'est important si ici je le dis p.ven et on va mettre à l'intérieur une fonction qui fera console point log et on mettra veine lorsque je sauvegarde on a hello ensuite on a les gens et ensuite seulement on a le veine parce que il exécute le fil principal c'est à dire qu'il exécute cette fonction là tout de suite qui fait le hello ensuite là il voit que c'est du code asynchrone donc le VN il se le met en attente lorsque la promesse sera résolue même si la promesse est résolue tout de suite ensuite il arrive au waiting il attend pendant deux secondes en bloquant totalement le script rien ne peut être fait il arrive aux consoles.log les gens et il l'affiche maintenant le fil principal est libéré et il peut attaquer le code asynchrones et du coup il se dit ah bah ce code là vu que la promesse est résolue je peux l'exécuter et du coup il affiche le console point longue de 20 donc même si ça paraît pas forcément super naturel au premier abord il faut bien comprendre comment fonctionne le système de fil principale et fil secondaire le Javascript va toujours exécuter en premier le fil principal et ensuite il va mettre en file d'attente les différentes les différents callbacks qui doivent être appelés et il les appelle dès que il a un petit moment de libre et c'est pour ça que ce vn là n'est pas exécuté tout de suite enfin dernier petit détail sur le Think n'utilisez le sint que si vous avez un away à l'intérieur ce n'est pas nécessaire d'utiliser un think si jamais vous renvoyez directement une promesse comme par exemple on a pu le faire pour Wade ou autre de la même manière si vous voulez renvoyer une promesse que vous transformez vous n'êtes pas obligé d'utiliser une fonction à synchrone typiquement imagine non on veut faire une fonction qui s'appelle wait andlock l'idée ça serait de lui passer une durée et un message à logué donc par défaut on aurait peut-être l'idée de se dire mais on va faire une fonction asynchrone et ensuite on va faire un weight on va attendre la durée qui a été indiquée et ensuite faire une console point loc de message donc ça c'est parfaitement valide mais ce que l'on peut aussi faire c'est ne pas du tout faire une fonction à synchrone et lui dire je veux faire un return de wait et lorsque ce cette promesse est résolue faire un vein et faire un console point log de mon message ça ça va avoir le même effet que ce que l'on a écrit avec le Think mais tant qu'une fonction renvoie une promesse elle pourra être utilisée après dans les aways et la synchrone voilà en fait ce qu'il faut vraiment éviter c'est les fonctions de cette manière là c'est écrire des a think en écrivant ensuite un return wait de ça ça n'a pas de pas d'intérêt là vous créez en fait un autre niveau de promesse pour rien et c'est de la perte de performance pour absolument aucun intérêt donc de temps en temps ça peut être plus pratique d'utiliser le point veine plutôt que de déclarer une fonction asynchrone pour rien parce que lorsque vous créez une fonction synchrone ça crée une nouvelle promesse qui est entoure votre mais pour l'instant ne vous prenez pas trop la tête sur ça au pire quand vous montrerez votre code à votre personne elle vous diront si peut-être vous avez utilisé un insigne pour rien voilà mais c'est pour vous montrer au cas où vous tombiez sur le sur l'exemple donc avec ce petit détail là on vient de terminer ce chapitre là donc vous le voyez les promesses vont nous permettre de représenter n'importe quel code qui peut fonctionner de manière à synchrone finalement on fait un new promise on passe ensuite une fonction dans cette fonction on fait ce que l'on veut donc on peut exécuter du code qui est assez synchrone comme le 7 times et lorsque notre promesse est résolue on peut utiliser resolve si notre promesse est en échec on ne sera rejette une fois que l'on a une promesse dans du code asynchrone on peut attendre la résolution de cette promesse beaucoup plus simplement et ça permet de créer un code qui est plus séquentiel et plus facile à lire là où avec syntaxe cette timante classique par exemple on avait ce système de callback l qui rendait le code difficile à lire là on le voit et quand on fait ce genre de code c'est beaucoup plus facile à comprendre parce que on est plus habitué à lire les choses de haut en bas plus que des parenthèses imbriquées et enfin on gardera dans un coin de notre tête les différentes méthodes qui permettent de combiner les promesses en fonction des situations donc suivant ce que l'on vous voudrez faire vous allez utiliser plutôt l'une ou l'autre de ces éléments là j'espère que j'ai été assez clair sur ce chapitre là et je vous donne rendez-vous dans un prochain chapitre ou justement on va avoir une fonction qui utilise les promesses c'est un des problèmes effectivement dans le langage mis à part une fonction la plupart des fonctions qui existent actuellement en Javascript vu qu'elles ont été créées avant l'apparition des promesses utilise ce système de Call pack comme par exemple cette taille menthe ce que vous pouvez faire et je vous inviterai de toute façon à le faire dans vos scripts c'est de transformer ces fonctions là avec des versions avec promesses typiquement cette fonction wait elle peut être très utile et du coup on se voit dans le prochain chapitre