Les fonctions fléchées : écrire moins, garder le contrôle

Ce que vous saurez faire

Écrire une fonction fléchée sans piège de syntaxe, expliquer d’où vient son this, et choisir en connaissance de cause entre la flèche et function. Tous les exemples se lisent dans la console du navigateur ou avec Node.js ; aucun serveur ni installation particulière.

1. Les formes d’écriture, et le piège des accolades

// Node.js ou console du navigateur.
const carre = (x) => x * x;
const direBonjour = () => 'Bonjour';
const enObjetFaux = (nom) => { nom };
const enObjet = (nom) => ({ nom });

console.log(carre(4));            // 16
console.log(direBonjour());       // 'Bonjour'
console.log(enObjetFaux('Jean')); // undefined
console.log(enObjet('Jean'));     // { nom: 'Jean' }

Les accolades sont ambiguës : après une flèche, elles délimitent un bloc d’instructions, pas un objet littéral. { nom } est donc lu comme un corps de fonction contenant l’expression nom, sans return : la fonction renvoie undefined. Les parenthèses lèvent l’ambiguïté.

Les parenthèses autour d’un paramètre unique sont facultatives en JavaScript, mais elles redeviennent obligatoires dès qu’il y a une valeur par défaut, un paramètre du reste, une décomposition, ou une annotation de type en TypeScript. Les garder systématiquement évite d’y penser.

Référence : fonctions fléchées.

2. this : ce que la flèche capture réellement

Pour une fonction classique, this dépend de la manière dont on l’appelle. Pour une fonction fléchée, il n’existe pas : le moteur va le chercher dans la portée englobante, comme n’importe quelle autre variable.

Or un objet littéral ne crée pas de portée. Une flèche écrite directement dans un objet, au niveau supérieur d’un fichier, capture donc le this de ce niveau supérieur — dont la valeur dépend du contexte d’exécution :

const utilisateur = {
  nom: 'Jean',
  parFleche: () => this?.nom,
  parMethode() {
    return this.nom;
  },
};

console.log(utilisateur.parMethode()); // 'Jean'
console.log(utilisateur.parFleche());  // undefined dans les trois contextes

Il ne s’agit donc pas d’une valeur unique et universelle. Ce qui est constant, c’est l’absence de this propre à la flèche, pas ce que this vaut. Le ?. est ici indispensable : dans un module ES, this vaut undefined et this.nom lèverait une TypeError.

Le mode strict change lui aussi le résultat, notamment quand on détache une méthode :

const afficher = utilisateur.parMethode;
afficher(); // mode strict : TypeError. Mode non strict : undefined.

En mode strict — celui des modules ES et des classes — this vaut undefined dans un appel sans receveur. En mode non strict, il vaut l’objet global, et la lecture renvoie simplement undefined sans erreur.

Référence : l’opérateur this.

3. Là où la flèche est exactement le bon outil

const panier = {
  nom: 'Panier',
  articles: ['pomme', 'poire'],
  lister() {
    return this.articles.map((article) => `${this.nom} : ${article}`);
  },
};

console.log(panier.lister());
// [ 'Panier : pomme', 'Panier : poire' ]

Ici la flèche est écrite à l’intérieur de lister(). Elle reprend donc le this de cet appel, c’est-à-dire panier. Avec function (article) { … }, this serait undefined dans un module et l’accès à this.nom lèverait une erreur.

Attention au cas symétrique : dans un gestionnaire passé à addEventListener, une fonction classique reçoit l’élément écouté comme this, une fonction fléchée non. Utilisez event.currentTarget, qui fonctionne dans les deux cas.

Pièges et limites

• Pas d’objet arguments. Une flèche n’en crée pas ; elle verrait celui de la fonction englobante. Utilisez un paramètre du reste : (...args) => args.length.
• Pas utilisable avec new. Une flèche n’est pas un constructeur et n’a pas de prototype ; new maFleche() lève une TypeError.
• Pas de remontée de déclaration. function estMajeur() {} est utilisable avant sa ligne d’écriture ; const estMajeur = … ne l’est pas, à cause de la zone morte temporelle.
• Méthode de classe écrite en champ fléché. clic = () => {} fige le this de l’instance, ce qui est pratique, mais crée une fonction par instance au lieu d’une seule sur le prototype.
• Lisibilité. Enchaîner a => b => c => … reste valide mais devient vite illisible ; nommer les étapes est souvent préférable.

À vous de jouer

Voici une fonction classique :

function estMajeur(age) {
  return age >= 18;
}

1. Réécrivez-la en fonction fléchée, dans sa version la plus courte.
2. Prédisez ce qu’affichent estMajeur(18) puis estMajeur(17).
3. Que se passe-t-il si vous appelez la version fléchée avant la ligne qui la déclare ?

Correction commentée

// Node.js ou console du navigateur.
const estMajeur = (age) => age >= 18;

console.log(estMajeur(18)); // true
console.log(estMajeur(17)); // false

Deux transformations se sont enchaînées. D’abord, function estMajeur(age) { … } devient une expression rangée dans une constante : const estMajeur = (age) => { return age >= 18; };. Ensuite, le corps ne contenant qu’un return, les accolades et le mot return disparaissent : l’expression age >= 18 devient directement la valeur renvoyée.

L’opérateur >= produit déjà un booléen ; écrire ? true : false serait redondant. Et comme cette fonction n’utilise pas this, la flèche ne présente ici aucun risque : c’est exactement le cas où elle est préférable.

Pour la troisième question : appeler estMajeur(18) avant la ligne const estMajeur = … lève une ReferenceError. La constante est bien réservée dans la portée, mais reste inaccessible jusqu’à son initialisation ; c’est la zone morte temporelle. Une déclaration function, elle, aurait fonctionné. La différence est réelle et n’a rien à voir avec this.

En TypeScript, la même fonction s’annote ainsi — et les parenthèses autour du paramètre deviennent alors obligatoires :

const estMajeur = (age: number): boolean => age >= 18;