JavaScript Promise : then() - async/await - fetch() en français

[@aliravakaandriamandimbisoa7346]

ah lala j'ai passé un bon moment en regardant et en recodant en même temps que ce tuto que vous avez fait. Chose que j'avais du mal à comprendre le fonctionnement de async/await et les fetch() , promesse... Au plaisir de découvrir d'autres vidéos intéressantes avec vous . Je vous remercie infiniment :D

[@codeconcept]

Content que cette vidéo fasse encore des heureux 😀

[@aminegh8725]

Honnêtement la meilleure vidéo qui démystifie vraiment la partie asynchrones, chapeau la tableau est peint toute est claire comme le soleil Merci infiniment.

[@codeconcept]

@aminegh8725 Merci !Je suis content que cette vidéo, enregistrée il y a un petit bout de temps maintenant, soit encore utile 👍

[@piranhasfr2963]

Le meilleur formateur JS en ligne !

[@codeconcept]

Merci Emmanuel :) Parfois la subjectivité ça a du bon :p

[@jlnko]

Merci pour tes vidéos, je suis en formation sur open classroom et je me décourageai et franchement tu m'a fait reprendre le rythme en suivant certaine de tes vidéos don't celle ci 🙏

[@codeconcept]

Merci Julien :) Je reçois régulièrement des témoignage d'apprentis devs en formation chez des gros, qui trouvent sur Code Concept ce qu'ils trouvent pas sur des grosses structures. Je fais finir par créer un open-codeconcept ou un oclockconcept pour redonner la foi aux devs dans la tourmente :D C'est normal de passer par des hauts et des bas pendant une reconversion. J'ai tendance à dire que la reconversion est un sport de combat. Il faut garder l'objectif final en tête quand on est dans le dur et se dire qu'en persévérant et pratiquant, un beau jour, le blocage sur un point précis tombe. Ca doit "juste" être le temps et la répétition nécessaires pour que les connexions neuronales se fassent. C'est la fameuse plasticité du cerveau. Elle n'est hélas pas instantanées comme c'était le cas pour Bradley Cooper dans 'Limitless', quand il prenait sa pilule qui lui permettait de tout comprendre instantanément. Au naturel, il faut qu'on répète jusqu'à l'illumination. J'ai vécu ça avec le passage à la programmation objet, puis la programmation fonctionnelle ;)

[@jlnko]

@@codeconcept oui surtout que j'ai 38 et mon début de vue à été très très festif jusqu'à à aller au fond, je remonte la pente depuis plusieurs années et le dernier pallier c'est arrivé à faire le job que je voulais faire à la base (dev si c'est pas clair 😂) mais dison que suivre une formation dans mon cas c'est devoir vivre avec le rsa, et franchement ça aide pas à libérer l'esprit, mais je me dis qu'au moins j'aurai acquis des bases et repris l'habitude de bosser seul, et depuis peu je me sert de chat gpt comme d'un mentor et c'est pas si mal. En tout cas merci 🙏

[@codeconcept]

Je connais hélas bien le temps passé à faire du calcul mental, les nuits d'insomnie particulièrement, à se demander comment faire avec du reste à vivre ... négatif. C'est pour ça qu'entendre un ministre nous expliquer qu'à 10000 € / mois (7500 après impôts), il avait du mal à acheter des pâtes à ses enfants, m'a fait, comment dirais-je, tomber de ma chaise. Mais c'était peut-être des pâtes aux truffes. 38 ans c'est encore jeune. Les recruteurs voudraient qu'on reste magiquement bloqués à 35 ans. Car avant, on peut avoir des enfants, après des ennuis de santé. Mais bon, au bout d'un moment, il faut bien mettre quelqu'un entre la chaise et le clavier pour développer ou maintenir des apps qui rapportent. Donc tu ne seras pas leur premier choix - comme tant d'autres parmi nous -, mais ça finira par le faire. Ils ne nous aiment pas et la réciproque est valable. Des sentiments partagés pour une fois : c'est pas beau ça ? Comme quoi, l'harmonie est possible :D

[@olivierdugast9309]

Il serait présomptueux de ma part de vouloir affirmer que cette video est certainement une des meilleures (voire la meilleure?) sur le sujet de l'asynchronisme en javascript. Mais par rapport à celles que j ai regardées par ailleurs, la tienne cerne très biens toutes les difficultés sans pour autant tomber dans trop de techniques et d'explications : un exemple très bien choisi, une progression limpide et un marquage très clair des points essentiels. Bravo!

[@codeconcept]

Merci Olivier ! J'ai effectivement beaucoup réfléchi à la façon d'aborder ce gros sujet qu'est l'asynchronie dans le dev contemporain. Content que tu aies apprécié le résultat :)

[@karenc8701]

Un immense merci pour cette vidéo j'en avais besoin ! 🙏 Je debute en JS (formation en cours) et c'est devenu tellement plus clair grâce à cet exemple très bien trouvé pour expliquer les notions, avec une cool attitude que j'adore je n'ai pas vu les minutes passées 👏😄

[@codeconcept]

Super sympa Karen : merci pour ce commentaire qui fait chaud au coeur :) Si c'est pas indiscret, tu fais quelle formation ?

[@karenc8701]

@@codeconcept formation école O'clock 😉

[@codeconcept]

Bon courage pour la reconversion : c'est un parcours du combattant qui en vaut la peine. Il ne faut pas se laisser décourager pour le progrès des IA. Les devs sont les mieux placés pour surfer cette vague ;)

[@senga9710]

bravo pour cette video très claire ! merci beaucoup, j'y ai compris beaucoup de choses !

[@codeconcept]

Merci Senga :) Content que cette vidéo soit utile. C'est tellement important les Promises quand on est développeur Front que le sujet valait bien une vidéo dédiée ;)

[@emiliep1732]

Purée merci pour cette vidéo, c'est clair comme de l'eau de roche, j'avais vraiment besoin de creuser ce point-là. C'est difficile au début de savoir quand en avoir besoin je trouve, comment organiser la chaîne des événements, mais ça vient avec la pratique j'imagine. Hop, abo, parce que bon ce n'est que le début d'une longue (infinie) aventure. Bon weekend tout le monde et bon code :)

[@codeconcept]

Merci Emilie :) Les promises sont tellement importantes depuis quelques années que c'est une bonne idée de leur consacrer un peu de temps. Elles nous le rendent bien par la suite. Il y aura une vidéo complémentaire qui permettra d'avoir une vue d'ensemble sur les interactions entre call stack, event loop, event queue etc car c'est souvent tout ce contexte qui permet de comprendre l'ordre d'exécution du code asynchrone et synchrone, tant côté client que serveur (en Node par exemple). Ca m'avait en tous cas beaucoup aidé de décoller le nez des seules promesses pour comprendre à quel moment elles sont exécutées. Bonne semaine et bon code également :)

[@nicolasmalet9267]

Parfait, merci beaucoup !

[@codeconcept]

Merci Nicolas :)

[@b-api2789]

Merci beaucoup pour ce contenu de qualité

[@codeconcept]

Merci b-api ... be happy ? :)

[@thibaultboutaud5216]

Merci pour le tuto doc :P

[@codeconcept]

Merci Thibault :D

[@trundra_ai]

t'es le boss

[@codeconcept]

Merci Andy :) Même si le boss c'est Bruce :p

[@Melvin-bh2op]

Génial

[@codeconcept]

Merci Melvin ;)

[@afrenchdude5331]

21:57 ça sent le vécu ^^

[@codeconcept]

En effet :D Je me suis retrouvé seul à aider un pote pour son déménagement alors qu'il avait toujours plein du monde fourré chez lui quand il s'agissait de vider des bouteilles. Et deux pour un déménagement, c'est vraiment le minimum du minimum.

[@mbsadem584]

bravo!!!

[@codeconcept]

Merci 😀

[@tenchigreed]

excellente video

[@codeconcept]

Merci Bot :p

[@dev-rachid]

👍

[@sebastien4444]

Bonjour, Il y a une chose que je n'ai pas comprise : quand vous utilisez then(), le code qui se trouve apres ('juste apres startDecisionProcess) s'affiche bien avant les 5000ms. Par contre, avec async await, il s'affiche apres les 5000ms --> l'odre des console.log n'est pas le meme. Du coup, on perd le concept d'asynchronisme, ce n'est pas du tout le meme comportement

[@codeconcept]

Bonjour, il y a en effet des cas où on ne peut PAS utiliser l'un à la place de l'autre. Pour une série de requêtes asynchrones où on doit attendre qu'une promesse soit résolue avant de faire la requête asynchrone qui suit, async await est plus lisible car on le lit comme du code synchrone. Mais il va en effet se mettre en pause jusqu'à la résolution de la promesse. Là où avec then(), l'exécution continue puis revient sur le then() lorsque la résolution de la promesse a eu lieu. En cas de doute, un point d'arrêt où des console.log() permettent de s'assurer que l'ordre est bien celui qu'on souhaite. Le truc, c'est qu'il faut connaître les deux syntaxes. Même si en 2024 on voit plus souvent async/await, les then() et catch() se rencontrent souvent dans le code un peu ancien.

[@sebastien4444]

@@codeconcept d'abord merci beaucoup pour la réponse, malgré les 2 ans écoulés depuis le post de la vidéo 😅. A titre personnel, j'utilise async await pour des fetch ou des requetes à une db afin d'etre sûr que le resultat attendu soit présent dans ma variable avant de pouvoir l'utiliser. J'avais moins cette notion d'asynchronisme où du code peut continuer à etre exécuté dans l'attente du resultat s'une promesse. À ce que je comprends, si c'est ce comportement que l'on souhaite, il faut forcément utiliser .then().catch() alors

[@rickydelaper9818]

Merci pour la vidéo !! Il me semble que le .json() donné par fetch parse plutôt le JSON vers un objet JS, d’où le fait qu’on le stringify ensuite pour récupérer du JSON à nouveau, ai-je bien raison ?

[@codeconcept]

Merci Ricky :) En effet, JSON.parse() créé un objet à partir d'une chaine, tandis que JSON.stringify() créé une chaine à partir d'un objet.

[@blr5538]

Merci pour cette vidéo très instructive. Y a t il des situations où il est préférable d'utiliser then() au lieu de await et vice versa.

[@florianginet8924]

c'est la meme , juste que async/await est plus moderne et lisible qu'un enchaînement de then()

[@codeconcept]

C'est en effet plus lisible avec async/await. La raison que je préfère, c'est quand on a besoin de valeurs intermédiaires (rasion 4) de ce blog post : hackernoon.com/6-reasons-why-javascripts-async-await-blows-promises-away-tutorial-c7ec10518dd9

[@GladiusPower]

Ça ressemble à ce que l on trouve dans d autre langage avec les try catch :)

[@codeconcept]

@@GladiusPower En effet :) De Java à C# en passant par PHP, on peut toujours compter sur un bon vieux try/catch ;)

[@florianginet8924]

Rafraîchissant !!

[@codeconcept]

:D C'est vrai que pour les anglophones cool c'est frais. A une époque, il fallait que ce soit "hot". Comme quoi, tout est histoire de température :p

[@olygood]

j'ai justement un problème avec l'audio sur un jeu html5 avec ou chrome me demande absolument de retourner une promesse pour l'audio ça tombe bien

[@codeconcept]

C'est un coup de pouce du destin alors ;) T'utilises quoi par curiosité pour créer ton jeu ? Phaser ?

[@olygood]

@@codeconcept purement HTML5, canvas, j'ai créer ma game loop, insérer les sprites,musiques, évent clavier, j'ai pleins d'idées tous les jours et pleins d'erreurs lol et demain je recommence avec webpack.et hier j'ai regardé 3fois ta vidéo pour voir si c'était possible de charger les les objets qui prennent plus de temps avec les promises et j'ai réussi la musique donc cool tes vidéos.

[@codeconcept]

@@olygood Wow, c'est courageux. Cette série d'articles de blog devrait t'intéresser alors spicyyoghurt.com/tutorials/html5-javascript-game-development/develop-a-html5-javascript-game

[@olygood]

@@codeconcept merci beaucoup

[@olygood]

je lit la doc que tu m'as envoyé c'est vraiment super, merci à toi

[@jean-bernardsaint-eve3340]

Merci pour cette vidéo en français. C'est clair maintenant. C'est sans doute la meilleurs vidéo en français (et j'en ai vu beaucoup, la pire étant celle de devTheorie -;) ) Je pense qu'il ne faut pas abuser de Async/await car sa rend le code synchrone (à mon avis de débutant) Je n'ai pas compris pourquoi le mot clé async était obligatoire devant une fonction comportant des await. Cette fonction est tout sauf asynchrone, vu qu'elle attend le résultat des await. Je n'ai trouvé aucune explication claire dans aucun tuto. J'ai compris que le async transforme la fonction en promesse. Mais pourquoi faire ?

[@codeconcept]

Merci Jean-Bernard :) async/await n'est QUE du sucre syntaxique. Il n''est pas plus bloquant que then(). En effet, en plaçant des console.log() à divers endroits comme je fais dans la vidéo, cela lève les doute. Par exemple async function getUserData(){ const response1 = await fetch('jsonplaceholder.typicode.com/users'); const users1 = await response1.json(); console.log("users1 first user email", users1[0].email); const response2 = await fetch('jsonplaceholder.typicode.com/users'); const users2 = await response2.json(); console.log("users2 first user email", users2[0].email); const response3 = await fetch('jsonplaceholder.typicode.com/users'); const users3 = await response3.json(); console.log("users3 first user email", users3[0].email); console.log("After all promise is executed"); } getUserData(); console.log("Hello World"); On voit bien que "Hello World" final est affiché en premier, malgré le fait que getUserData() est avant et est une fonction async et qu'elle contient des await fetch(). Le résultat dans la console est en effet : "Hello World" "users1 first user email" "[e-mail]" "users2 first user email" "[e-mail]" "users3 first user email" "[e-mail]" "After all promise is executed" J'ai tiré cet exemple de cet article dont j'ai un peu modifié le corps de getUserData() medium.com/geekculture/does-async-await-block-javascript-main-thread-c07db9c48c3e#:~:text=Though%20it%20creates%20a%20confusion,syntactic%20sugars%20for%20promise%20chaining. Ce qu'il manque pour comprendre pourquoi des choses sont bloquantes et pourquoi d'autre ne le sont pas, c'est une vue d'ensemble qui englobe les interactions entre call stack, event loop l'event queue etc. Je ferai une vidéo là dessus ;) Edit : jusqu'à il y a peu, on ne pouvait utiliser await que dans le corps de fonctions async, mais il semble que les 'top level' await soient déjà utilisables dans le contexte de modules JavaScript : developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/await

[@medaillonet]

Je me sers pas mal du fetch(), des promesse, d'async/await en ce moment et ta vidéo me fournit de bons rappels de ces notions merci. Question : en fait pour le dernier exemple, lorsque tu code la fonction async searchGithub(), il n'y pas de .catch en fait ? en cas d'erreur de retour du fetch ?, Si on l'avait voulu il aurai fallu utiliser un try/catch ? Puis en plus tu fais trop marrer avec tes critères de recrutement et tes exemples/commentaires. J'ai énormément pensé à cette song lors du tuto : kzbin.info/www/bejne/bX3aeoOkep5nbtk

[@codeconcept]

Merci :) En effet, avec async.await, on ajoute généralement un try/catch qui engloble le code qui pourrait échouer. Voilà un exemple tiré de MDN : developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Statements/async_function async function getProcessedData(url) { let v; try { v = await downloadData(url); } catch(e) { v = await downloadFallbackData(url); } return processDataInWorker(v); } Quant aux critères de recrutement, je ne dis pas un dixième de ce que je pense tant les bras m'en tombent quand j'entends, encore de nos jours, certaines présentations marketing/corporate/RH qui vendent du rêve au candidat qui, avec un peu d'expérience, sait qu'il est une "resource" sur un fichier excel ... :p

[@nicolasmalet9267]

Merci, j'avais déjà du mal à me concentrer mais la 😀

[@kernelpanic666]

Top le tuto mais trop de pubs j'ai abandonné en cours de route...

[@codeconcept]

Merci Ling 😀 Sur des tutos longs non-sponsorisés, la pub est nécessaire. Mais tu peux utiliser adblock si elle est trop envahissante 😉

[@kernelpanic666]

J'essaierais car là c'était trop ^^@@codeconcept

[@codeconcept]

Alternativement, sur le Teachable de Code Concept, il y a des milliers de vidéos (réunies dans une quarantaine de formation) et zéro pub ... mais c'est payant. codeconcept.teachable.com/ 😁 C'est le fameux "si c'est gratuit, c'est toi le produit" du marketing contemporain.