Tu l'as déjà entendue celle là, non ?


"Moi, je préfère utiliser les fonctions fléchées, car le comportement est beaucoup facile à prévoir et le code plus facile à lire".
Mouais... Quand on fait des bind à tour de bras, pour se débarasser vite fait, alors je comprends qu'on puisse dire ça. Mais vite fait alors, hein. Parce que le problème des fonctions, c'est pas vraiment de savoir qui les exécute : c'est toujours celui qui sait le faire. Quand on code une "class" comme ça : 
class MyClass {
  prop = "une pseudo classe";


  mafonction() {
    function f() {
      console.log(this.prop);
    }
    f();
  }
}

const instance = new MyClass();

C'est qu'on aurait mieux fait de rester couché le matin.

Que fait cette fonction f déclarée ici en plein milieu ? C'est comme de penser une fonction "soulève 130 kg" et ensuite de penser que tout le monde va pouvoir s'en servir. Avant de définir cette fonction, il va bien falloir trouver le bonhomme capable de l'exécuter.

Si on fait :
instance.mafonction();
comme f ne s'exécute pas toute seule, elle va se demander qui est le bonhomme (this) qui est supposée la réaliser.

Les fonction fléchées permettent souvent de palier au problème en laissant croire que le this sera appelé au moment de son exécution.
Si on met une fonction fléchée à la place, ça va fonctionner "magiquement" !

Alors entendons nous bien : tu fais comme tu veux et tu as le droit de dire ça. Mais s'il te plait, évite de donner des conseils et surtout de prétendre que le fait que ce code est pourri est la raison pour laquelle il faut écrire des fonctions fléchées.

La fonction fléchée permet de capturer le contexte et blablabla...

Oui, le contexte :

Mais non, les fonctions fléchées ne rebindent PAS this, arguments, super ni new.target...

Alors je ne sais pas qui peut dire (si, moi, bien énervé, je peux le faire) mais surtout écrire "Je préfère utiliser les fonctions fléchées" sans me laisser à penser qu'il n'a pas bien compris le principe et se contente encore une fois d'appliquer ces fameuses "bonnes pratiques" qui me hérissent le poil.

Et puis franchement, c'est fatiguant de la déclarer proprement cette fonction si tu penses avoir compris ce qu'est une classe en JS ?

class MyClass {
  prop = "une pseudo classe";

	function f() {
	console.log(this.prop);
	}
	mafonction() {
	this.f();
	}
}
const instance = new MyClass();
instance.mafonction();

La vérité...

Image

📜 Fiche mémo – function() {} vs () => {} en JavaScript

function() {} classique

Aspect Description
this Dynamique ➔ dépend de l'objet qui appelle la fonction.
Utiliser pour Méthodes d'objets (onPress, onRollOver, listeners DOM, canvas clips...)
Exemple concret btn.onPress = function() { this._parent.locked = true; }
Pourquoi ? Parce que this doit être l'objet qui reçoit l'événement.

() => {} fléchée

Aspect Description
this Lexical ➔ capturé au moment de la définition du code.
Utiliser pour Fonctions simples, callbacks map, filter, setTimeout, etc.
Exemple concret [1,2,3].map(x => x * 2)
Pourquoi ? Parce que pas besoin de this, ou besoin de garder le this du parent englobant.

❌ Mauvais usage typique (pas parce que c'est pas bien, parce que cela ne fonctionne pas)

btn.onPress = () => {
if(this._parent.locked === true){....; // 💥 this = parent lexical au moment de la déclaration, pas btn !
//this._parent.locked ne sera jamais remis à jour !
};

⛔ Résultat : le bouton ne sait plus qui il est, tout pète silencieusement.

✅ Usage pour un moteur Canvas / DOM / Scène qui fonctionne 

btn.onPress = function() {
if(this._parent.locked === true){....; // ✅ this = btn, tout est logique et la valeur de locked sera celle attendue au moment où tu t'en sers.
};

✔️ Résultat : this est bien le bouton cliqué.

📢 Rappel

💬 En résumé court pour affichage studio :

"Pas de flèche sur les objets vivants." (boutons, canvas, listeners, DOM events...)

🎯 Encore plus simple en slogan :

Cas Solution
Je gère un bouton, un clip, une scène function() {}
Je fais une fonction courte sans this () => {}

Des paroles de sage :
« Avant de discuter comment on écrit (function ou flèche), il faut vérifier où on écrit (instance, structuration, responsabilité). »