Merci pour la précision , finalement c'est bien pour tester des choses ou faire des exemple ( si ce n'est que du coup ce n'est pas un bonne exemple pour les nouveau de l'écrire de cette manière) , j'ai une question parceque du coup y'en a qu'il le font aussi pour faire "moins de ligne de code", mais es que finalement le fait d'avoir des fonction anonyme comme ça ne demande pas plus de travaille à la machine ? Alors que si les fonction sont nommer le processus de lecture du code devrait si retrouver plus facilement (je ne sait pas vraiment comment appeler cela , j'espère que tu voit ce que je veut dire ) , cela m'intéresse de savoir si c'est une sorte d'équilibre entre le moin de ligne de code possible mais demande peut etre plus de travaille, ou plus de ligne de code mais peut etre plus de facilité de lecture de code pour la machine donc plus rapide ? (je me doute également que c'est plus pratique également de toute manière pour ceux qui repasse sur le code et le cas du remove) , je suis curieux de savoir , j'espère avoir bien formuler ma question , merci
C'est bien de se poser des questions, mais il n'y a pas de différences de performance entre l'utilisation d'une fonction anonyme et la création d'une fonction séparée. D'ailleurs la fonction séparée est même réutilisable. Aussi, moins de ligne de code ne veut pas forcément dire "code de meilleure qualité". Créer une fonction séparée est plus maintenable. 👍
Oh ☹, mais j'adore les fonctions fléchées ! Tellement plus pratiques (le this..) et lisibles (avis perso) que les autres manière de faire. Les fonctions fléchées c'est presque LA raison pour laquelle j'aime le JS. Ce serait tellement triste sans elles.
L'utilisation de la fonction flechée change aussi le contexte du mot clé "this" ce qui, dans certains cas, peux poser des soucis. h1.addEventListener("click", () => { console.log(this); // window }); h1.addEventListener("click", function foo() { console.log(this); // h1 });
@@lmz-dev le mieux reste quand même de les déclarer en les nommant au bon endroit du code pour bien organiser ses blocks puis de les appeler en leur passant l'event, je trouve. Infiniment moins chiant à relire et rectifier, non ?
3:07 Comment résoudre ce problème. En nommant la fonction. Et pourquoi à la ligne 3, la nommer ? A moins qu'une fonction dans une fonction, ne soit pas aussi une bonne pratique?) Exemple : 3 card.AddEventListener("mousemove", handleMousemove() { card.classicList.add(animated)}
Bonne idée mais c'est incorrect. La fonction que tu as nommée dans l'appel à addEventListener n'est pas accessible pour un removeEventListener situé dans un contexte d'exécution supérieur, ce qui ne résout donc pas le problème.
Je pense que c'est lié au fuites de mémoire que le garbage collectore, ne sais pas gérer. A ce sujet, il y a une vidéo "plus détaillée" : th-cam.com/video/SVb9b6-D2-0/w-d-xo.html
Y a le setTimeout et setInterval qui auraient pu être dans cette video si jme trompe pas
C'est à dire ?
@ je veux dire le fait de penser à les mettre dans une variable pour pouvoir les nettoyer
@@Azer_Oner Ah oui bien-sûr 👍
Merci pour la précision , finalement c'est bien pour tester des choses ou faire des exemple ( si ce n'est que du coup ce n'est pas un bonne exemple pour les nouveau de l'écrire de cette manière) , j'ai une question parceque du coup y'en a qu'il le font aussi pour faire "moins de ligne de code", mais es que finalement le fait d'avoir des fonction anonyme comme ça ne demande pas plus de travaille à la machine ? Alors que si les fonction sont nommer le processus de lecture du code devrait si retrouver plus facilement (je ne sait pas vraiment comment appeler cela , j'espère que tu voit ce que je veut dire ) , cela m'intéresse de savoir si c'est une sorte d'équilibre entre le moin de ligne de code possible mais demande peut etre plus de travaille, ou plus de ligne de code mais peut etre plus de facilité de lecture de code pour la machine donc plus rapide ? (je me doute également que c'est plus pratique également de toute manière pour ceux qui repasse sur le code et le cas du remove) , je suis curieux de savoir , j'espère avoir bien formuler ma question , merci
Oui, arrêtons de pisser du code pour rien. Si c'est plus court, c'est bon pour la planète ;p
C'est bien de se poser des questions, mais il n'y a pas de différences de performance entre l'utilisation d'une fonction anonyme et la création d'une fonction séparée.
D'ailleurs la fonction séparée est même réutilisable.
Aussi, moins de ligne de code ne veut pas forcément dire "code de meilleure qualité".
Créer une fonction séparée est plus maintenable. 👍
@@EcoleduWeb Merci pour votre réponse, oui je voulait juste savoir cela m'intéresser.
@@EcoleduWeb Les pures maintiennent du code uglifié 😎 😁
Bonne précision, merci :)
Oh ☹, mais j'adore les fonctions fléchées ! Tellement plus pratiques (le this..) et lisibles (avis perso) que les autres manière de faire.
Les fonctions fléchées c'est presque LA raison pour laquelle j'aime le JS. Ce serait tellement triste sans elles.
Tu peux les utiliser à énormément d'endroits sans problème, simplement pas ici. 👍
Premier commentaire 0:20
L'utilisation de la fonction flechée change aussi le contexte du mot clé "this" ce qui, dans certains cas, peux poser des soucis.
h1.addEventListener("click", () => {
console.log(this); // window
});
h1.addEventListener("click", function foo() {
console.log(this); // h1
});
h1.addEventListener("click", e => console.log(e.target)); //› h1
@@lmz-dev le mieux reste quand même de les déclarer en les nommant au bon endroit du code pour bien organiser ses blocks puis de les appeler en leur passant l'event, je trouve. Infiniment moins chiant à relire et rectifier, non ?
@@n.nonyme On est d'accooooord ! Là je montre juste qu'on peut s'en sortir sans l'opérateur this pour un écouteur ;p
@@lmz-dev ah bien d'accord ! Merci et bonne journée
3:07 Comment résoudre ce problème. En nommant la fonction. Et pourquoi à la ligne 3, la nommer ? A moins qu'une fonction dans une fonction, ne soit pas aussi une bonne pratique?) Exemple : 3 card.AddEventListener("mousemove", handleMousemove() { card.classicList.add(animated)}
Bonne idée mais c'est incorrect.
La fonction que tu as nommée dans l'appel à addEventListener n'est pas accessible pour un removeEventListener situé dans un contexte d'exécution supérieur, ce qui ne résout donc pas le problème.
@@EcoleduWeb En effet. Mon fils me l"a fait remarquer. Par contre il n'"a bien "vue" l'intérêt de supprimer cette fonction.
Je pense que c'est lié au fuites de mémoire que le garbage collectore, ne sais pas gérer. A ce sujet, il y a une vidéo "plus détaillée" : th-cam.com/video/SVb9b6-D2-0/w-d-xo.html
du coup, je me demande, si passer par TypeScript, pourrais éviter tout ces "pièges" dont nous n'avons pas conscience?