En réalité je l'ai très bien compris, que c'est juste du sucre syntaxique, mais en vrai c'est pas complètement pareil (tout dépend comment sont utilisés les promesses, chaînées ou non, etc) j'ai juste corrigé mon post entre temps (à force de pratiquer plein de langages différents on fini par s'embrouiller) d'où d'ailleurs mes raturages − n'aimant pas cacher mes erreurs, je préfère les assumer.
Ceci dit, je trouve la solution des promesses bien plus élégante à lire, et je pratique cette tournure plutôt que le await/async. D'un certain côté, une fois que t'as commencé à partir dans le fameux "promise hell", si ton code n'est pas bien structuré, ça devient vraiment un enfer, mais si ton code est bien structuré, c'est très élégant: avec ça tu détecte les conneries architecturales assez rapidement.
Mais les JS-eux adorent await/async, beaucoup n'aiment pas les promises, malgré mon petit caffouillage, ça ne méritait pas forcément de passer dans le négatif, c'est une alternative à la fois tout aussi élégante, mais aussi dans certains cas plus pertinent. De plus, ça force à écrire les fameuses callback dont parle l'auteur, mais avec une variante en utilisant la "arrow syntax" (qui ne propage pas le this dans les callback), qui est courte et élégante.
Avec cette syntaxe, une autre chose que j'aime bien: on a pas besoin de déclarer ses variables (const toto) vu qu'on les récupère directement en paramètre des closures et on peut arriver à un stade où on peut considérer que déclarer des variables est une erreur de programmation: on rajoute des embranchements et la complexité cyclomatique et donc on augmente la probabilité d'avoir des bugs (certains analyseurs statiques d'ailleurs mettent ça en valeur).
Par ailleurs, avec les promesses, on ne mélange pas les scopes, et donc on ne partage pas les variables: on réduit par la même occasion les chances d'écrasement ou d'utilisation de variable accidentels de par cette isolation, le code est potentiellement plus robuste (pas forcément plus robuste à l'exécution, mais plus résistant à l'erreur humaine).
[^] # Re: Tu tiens pas tes promesses
Posté par Christie Poutrelle (site web personnel) . En réponse au journal recherche-totoz en JavaScript. Évalué à 2. Dernière modification le 30 novembre 2018 à 15:09.
En réalité je l'ai très bien compris, que c'est juste du sucre syntaxique, mais en vrai c'est pas complètement pareil (tout dépend comment sont utilisés les promesses, chaînées ou non, etc) j'ai juste corrigé mon post entre temps (à force de pratiquer plein de langages différents on fini par s'embrouiller) d'où d'ailleurs mes raturages − n'aimant pas cacher mes erreurs, je préfère les assumer.
Ceci dit, je trouve la solution des promesses bien plus élégante à lire, et je pratique cette tournure plutôt que le await/async. D'un certain côté, une fois que t'as commencé à partir dans le fameux "promise hell", si ton code n'est pas bien structuré, ça devient vraiment un enfer, mais si ton code est bien structuré, c'est très élégant: avec ça tu détecte les conneries architecturales assez rapidement.
Mais les JS-eux adorent await/async, beaucoup n'aiment pas les promises, malgré mon petit caffouillage, ça ne méritait pas forcément de passer dans le négatif, c'est une alternative à la fois tout aussi élégante, mais aussi dans certains cas plus pertinent. De plus, ça force à écrire les fameuses callback dont parle l'auteur, mais avec une variante en utilisant la "arrow syntax" (qui ne propage pas le this dans les callback), qui est courte et élégante.
Avec cette syntaxe, une autre chose que j'aime bien: on a pas besoin de déclarer ses variables (const toto) vu qu'on les récupère directement en paramètre des closures et on peut arriver à un stade où on peut considérer que déclarer des variables est une erreur de programmation: on rajoute des embranchements et la complexité cyclomatique et donc on augmente la probabilité d'avoir des bugs (certains analyseurs statiques d'ailleurs mettent ça en valeur).
Par ailleurs, avec les promesses, on ne mélange pas les scopes, et donc on ne partage pas les variables: on réduit par la même occasion les chances d'écrasement ou d'utilisation de variable accidentels de par cette isolation, le code est potentiellement plus robuste (pas forcément plus robuste à l'exécution, mais plus résistant à l'erreur humaine).