Les fonctions fléchées c’est pas la panacée !

Je vois les gens se jeter sur les fonctions fléchées sans trop réfléchir, par flemme ou effet de mode, peu importe. Il faut tout de même garder à l’esprit qu’elles ne constituent pas une panacée ! Il y a plusieurs cas pour lesquels elles sont même contre-indiquées :

  1. Si je veux tirer parti du hoisting que JavaScript applique aux déclarations de fonctions traditionnelles, c’est-à-dire permettre à mon code d’appeler une fonction plus haut, dans mon code source, que sa déclaration, je dois justement utiliser une déclaration de fonction, pas une expression de fonction. Les fonctions fléchées étant par nature des expressions, ça ne marchera pas. Si vous n’êtes pas au point sur le hoisting, qui est un concept bien pratique, je vous ai mis un petit lien francophone ici qui explique ça plus en détail ; on en reparle aussi en détail dans notre cours vidéo Faire du JavaScript asynchrone moderne, et naturellement dans notre super formation ES Total.
  2. Si, justement, j'ai besoin que le code qui appelle ma fonction puisse en définir explicitement le this, par exemple pour la passer à des API dont le contrat le nécessite, comme on a pu le voir tout à l’heure, je ne peux pas utiliser une fonction fléchée ! Gestionnaires d’événements ayant besoin d’accéder à l’objet cible ou au flux, fonctions de test ayant besoin de personnaliser la valeur de timeout… tout ça nécessite une fonction traditionnelle afin que le code appelant puisse mettre le bon this en place.
  3. Histoire de me faire l’avocat du diable, je mentionne aussi le souhait de recourir à arguments, mais en fait depuis ES2015 on évite ça lorsqu’on veut manipuler nos arguments : on préfèrera une syntaxe de rest dans la signature, pour obtenir un véritable tableau, plutôt que cette valeur peu pratique. Et si vous avez les fonctions fléchées, par définition, vous êtes au moins en ES2015.

Ne viens pas la jouer pédante

À ce stade je me permets un petit aparté à destination de ceux qui ne pourraient pas s’empêcher de la ramener dans les commentaires (il y en a toujours, hélas) en disant que non, c’est pas tout à fait comme ça, en fait le moteur décide de la résolution parce que patati et patata…

Alors oui, bien sûr, j’ai un tout petit peu simplifié le truc (parce qu’en vrai, on est en fait très très près du noyau d’implémentation, là), mais je vous rappelle qu’on n’est pas en train de coder un moteur JavaScript. Je trouve qu’on va déjà largement assez loin pour expliquer proprement, et de façon précise et juste, le comportement de this, qui est le sujet du cours, je vous rappelle.

Après si tu as envie de faire ton rageux, souviens-toi juste que je sais pertinemment que le FER est initialisé en consultant le slot interne [[ThisBindingStatus]] pour voir si elle vaut 'lexical' (comme l’explique la section 8.1.1.3 de la spec, tu l’as lue, toi ?), que même ça c’est défini par le slot interne [[ThisMode]] de la définition de la fonction (section 8.1.2.4), lequel est calé à 'lexical' pour les fonctions fléchées (section 9.2.4), etc. Je collabore au TC39 et je lis la spec, et je dis que sur ce coup, on a été bien assez loin comme ça, et que ça n’appelle aucun « oui, mais… ».

Je t’invite donc à garder ton énergie de commentaire pour un truc plus constructif, OK ?

JavaScript : this is it

Vous allez enfin comprendre comment this fonctionne en JavaScript… et ça vaut le coup !