Re: Tu tiens pas tes promesses

En quoi utiliser des fonctions avec l'arrow syntax est plus court et élégant que ne pas en utiliser du tout ?

Tout dépend des conventions et de l'usage, d'un point de vue syntactique pur, ça rend ce que t'écris plus court, et te permet de te focaliser sur l'essentiel. Dans tous les cas, à un moment ou un autre, tu vas écrire des fonctions, qu'elle soit nommées ou anonymes (en JS elles sont toutes des closures donc je ne distingue pas ici). Donc finalement, parfois c'est plus judicieux de l'écrire à l'endroit où tu l'utilises, et puisqu'elle a un usage unique, tu n'as pas besoin de la nommer, donc moins de surcharge cognitive.

D'un autre côté, dans la sémantique du langage en lui même, la short arrow syntax ne se comporte pas comme les closures avec function() ou les fonction nommées, à savoir que dès lors que tu utilises une function (nommée ou non) elle dispose de son propre this, elle est un objet, elle a un état: une closure sous la forme d'une short arrow function n'a pas d'état, elle est plus proche du fonctionnel pur. D'ailleurs c'est parfois pratique car dans le contexte d'une instance, le this dans ta short arrow function va être celui de l'objet (comme le comportement des closures en PHP, et sûrement dans d'autres langages) - ça te permet de propager des comportements d'objets isolés dans du code événementiel, et dans certains cas, améliore grandement la lecture.

Absolument pas. Non seulement c'est possible de ne pas déclarer de variables temporaires avec async/await, mais surtout en déclarer n'est pas une erreur de programmation et rend le code plus clair.

Je n'ai pas dit que c'était une erreur dans l'absolu, mais que dans certaines conventions, ça peut être considéré comme tel. Et d'ailleurs, en ce qui concerne "rend le code plus clair" je ne suis foncièrement pas d'accord, ça relève du subjectif, mais passer par moult variable créé une surcharge cognitive, tout dépend de comment le lecteur lit bien entendu.

ajoute quoi que ce soit en complexité par rapport à f3(f2(f1())).

Dans l'absolu, c'est vrai, après, certains analyseurs statiques vont donner un score plus élevé à la complexité dès lors que tu rajoutes des variables temporaires. Même si sémantiquement c'est exactement la même chose, dans certains langages interprétés l'exécution n'est pas équivalente, même si le résultat est le même (par exemple, le simple fait de créer la variable intermédiaire peut être un overhead, exemple en PHP, et sûrement dans certaines VM JS aussi, sauf si par chance ton code est beaucoup exécuté et que la JIT décide de le compiler autrement). C'est sûrement pour ça que ces analyseurs le mesure d'ailleurs.

Dans l'exemple, tout est déclaré avec le mot-clé const, rien ne peut être écrasé. Par ailleurs rien n'empêche d'appliquer les bonnes pratiques comme donner des noms clairs aux variables et écrire des fonctions courtes en utilisant async/await.

En effet, const est une bonne pratique, d'ailleurs en Scala une des pratiques couramment admise est que rien ne devrait pas être const, et je pratique moi même cette règle quand j'écris en TypeScript. Sauf parfois dans le cas d'une variable dans un bouboucle for in ou for of, mais je conserve le for uniquement quand ça fait sens d'un point de vue performance ou sémantiquement - comme par exemple avec les NodeList en retour d'un querySelectorAll(), qui n'est ni un Array ni finalement vraiment un enumerable, sinon Array.forEach() est très bien, mais très lent, et malheureusement ne peut pas être utilisé dans certains cas.

async/await c'est très bien, je ne suis pas contre, il ne faut pas le prendre sur ce ton ! J'espère que tu as remarqué que je ponctue énormément ce que j'écris avec "parfois", "dans certains cas", "sous certaines conventions" et j'en passe. D'ailleurs j'utilise beaucoup plus le mot-clé async, qui permet d'écrire la fonction asynchrone de façon beaucoup plus claire et beaucoup plus concise, sans avoir besoin de manipuler soit même l'objet Promise, qui rend le code extrêmement verbeux, surtout en TypeScript avec du typage fort, mais la réciproque, dans mes cas d'usage courants, n'est pas vraie, j'utilise plus souvent explicitement some_function().then().then().catch() que await.

Après, les goûts et les couleurs, mais il ne faut pas s'énerver comme ça !