Discussion :

[adiGuba]

Salut,



Je n'ai pas vraiment trouvé d'info : je voudrais savoir les bonnes pratiques vis à vis des listeners.
En particulier : doit-on supprimer les listeners d'un élément du DOM lorsqu'on supprime cet élément du DOM de la page ?


Explication : je dispose d'une application web en AJAX dans laquelle on passe de vue en vue sans recharger la page.
Chacune de ces vues correspond à un element DOM créé dynamiquement, et comportant plusieurs éléments avec divers listeners ajoutés via addEventListener().

A chaque changement de vue, on regénère donc une nouvelle vue que l'on place dans la page, en remplacement de la vue précédente.


Mais je ne supprime pas les listeners via removeEventListener().
Est-ce correct ? Sachant que je n'ai plus de référence vers ces éléments, et qu'ils ne sont plus présent dans le DOM.

Est-ce que je devrais conserver tout cela pour les supprimer lorsque je supprime la vue de la page ?





a++

[SylvainPV]

Tout dépend de la façon dont le listener est attaché, s'il s'agit d'évènements délégués ou non. Prenons un exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
//évènement rattaché
document.body.querySelector("button").addEventListener("click", function(){ alert('clic'); }); 
 
//évènement délégué
document.body.addEventListener("click", function(event){
  if(event.target.tagName == "button"){
      alert('clic');
  }
});

Avec un évènement rattaché, le listener est lié à l'élément. Donc si l'élément est supprimé, le listener aussi, tout est clean.
Au contraire, avec un évènement délégué on demande à un élément parent (généralement le document ou window) d'intercepter tous les évènements d'un certain type, puis de vérifier d'où provient l'évènement et s'il correspond au sélecteur désiré. L'avantage, c'est qu'on peut ajouter et retirer dynamiquement des éléments dans la page sans avoir à se soucier de si les listeners ont été ajoutés ou pas. L'inconvénient, c'est que si l'on souhaite retirer ses listeners, il faut le faire manuellement avec removeEventListener (ou supprimer l'élément parent mais quand il s'agit de window, c'est plutôt ennuyeux )

[Bovino]

Il y a d'autres éléments à prendre en considération.
Si l'élément auquel tu attaches l'événement correspond à une variable :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
var elem = document.createElement('div');
elem.addEventListener('click', function(){
    alert('cliqué');
});

supprimer l'élément du DOM ne supprimera pas le listener.
D'autre part, tu ne peux pas supprimer un listener avec removeEventListener si le callback est une fonction anonyme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
var elem = document.createElement('div');
elem.addEventListener('click', function(){
alert('cliqué');
});
elem.removeEventListener('click', function(){
alert('cliqué');
});
elem.click();

[adiGuba]

@SylvainPV : Je parle bien d'évènement attaché directement sur un élément et non pas délégué sur un parent.


@Bovino : Les évènements sont attaché à une variable (un peu comme dans ton code).
Mais cette variable n'est plus accessible dans le code et elle est supprimé du DOM.

Dans ce cas le listener est toujours en mémoire et je devrais le supprimer ?



Je vais essayer de faire un code minimal pour me faire comprendre.
(je peux pas donner mon code car ce n'est pas réellement du JavaScript. Il est généré).


a++

[adiGuba]

Voilà grosso-modo un exemple de code : http://jsfiddle.net/AG292/


La page contient 3 boutons et un container de base.
Lorsqu'on clique sur un des boutons, le contenu précédent est supprimé du container (avec removeChild()), et on y insère un nouvel élément avec un évènement associé.

Cet évènement doit-il être supprimé lorsque je change de vue via un bouton ?
Le fait de supprimer l'élément du DOM et ne plus avoir de variable le référençant n'est-il pas suffisant ?


a++

[NoSmoking]

Bonjour,
en fin de ta fonction il te suffit de "déréférencer" l'élément, elem = null;

[adiGuba]

en fin de ta fonction il te suffit de "déréférencer" l'élément, elem = null;

C'est pas automatique çà vu qu'il est déclaré en var à l'intérieur de la fonction ?


a++

[NoSmoking]

La variable n'est pas utilisable en dehors de la fonction mais dans la mesure où elle possède une référence à un objet, le garbage collection ne libère pas la mémoire qu'il occupe.

[adiGuba]

Waouh ! C'est sûr ?

J'aurais penser que le GC était suffisamment "intelligent" pour faire cela lui même...
Du coup ca me fait encore plus peur ce truc !


a++

[SylvainPV]

Une minute, même si la variable garde une référence à l'objet, à partir du moment où on quitte la fonction et où elle n'est plus accessible d'ailleurs, le garbage collector fait bien le boulot et il n'y aura pas de fuite mémoire. J'ai récemment corrigé les fuites mémoires sur un projet pro, 99% des cas étaient des listeners d'évènements délégués oubliés. Une fois ceux-ci enlevés, plus aucun problème de mémoire et sans avoir eu besoin de mettre les variables comme elem à null. Il faut juste faire gaffe à ne pas déclarer les variables comme elem dans des closures persistantes.

[Bovino]

Tout à fait Sylvain. Il me semble que les navigateurs modernes savent très bien gérer ces références croisées.

Pour info, les plus gros problèmes de fuite de mémoire étaient liés à IE du fait de son modèle JScript dont une partie (le core JavaScript en gros) dépendait directement de l'OS alors que la partie DOM dépendait de IE. Du coup, les références croisées impliquant les deux couches n'étaient pas résolues par le garbage collector. Mais ce n'est plus vrai depuis un moment il me semble.

[adiGuba]

Une minute, même si la variable garde une référence à l'objet, à partir du moment où on quitte la fonction et où elle n'est plus accessible d'ailleurs, le garbage collector fait bien le boulot et il n'y aura pas de fuite mémoire.

Ouf ca me rassure !

Pour info, les plus gros problèmes de fuite de mémoire étaient liés à IE du fait de son modèle JScript dont une partie (le core JavaScript en gros) dépendait directement de l'OS alors que la partie DOM dépendait de IE. Du coup, les références croisées impliquant les deux couches n'étaient pas résolues par le garbage collector. Mais ce n'est plus vrai depuis un moment il me semble.

IE je me contenterais d'un fonctionnement correct sur les versions récentes (IE10, voir IE9).

Les versions précédentes sont supporté (on corrige les bugs bloquants s'il y en a), mais on ne vas pas chercher à améliorer le code spécifiquement.


a++

[Bovino]

IE je me contenterais d'un fonctionnement correct sur les versions récentes (IE10, voir IE9).

Dans ce cas, je pense qu'il n'y aura pas de problème.

mais on ne vas pas chercher à améliorer le code spécifiquement.

Voilà une démarche intelligente, c'est pas courant... tu féliciteras ton chef de projet

[adiGuba]

tu féliciteras ton chef de projet

Chut on ne lui a pas dit !


Non plus sérieusement ca fait quelques temps qu'on a pris cette démarche.
On gère autant que possible les bugs bloquants, mais on ne recherche pas la fidélité absolu ou l'exécution parfaite sur les anciens navigateurs...


a++

[NoSmoking]

Il me semble que les navigateurs modernes savent très bien gérer ces références croisées.

j'en étais resté au fait que courant 2012 le nouvel algo devait être implémenté dans les navigateurs modernes mais sans avoir suivi plus que cela l'évolution, j'en prend bonne note sachant quand même que des IE9 (et -) il doit en trainer encore un sacré tas.

Si l'élément auquel tu attaches l'événement correspond à une variable :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
var elem = document.createElement('div');
elem.addEventListener('click', function(){
    alert('cliqué');
});

supprimer l'élément du DOM ne supprimera pas le listener.

donc la mise en place d'un elem=null reste donc la solution, pour au moins les navigateurs anciens ?

J'ai récemment corrigé les fuites mémoires sur un projet pro, 99% des cas étaient des listeners d'évènements délégués oubliés.

tu veux dire que lorsque qu'un élément, sur lequel on a placé un "écouteur délégué", est supprimé ce listener n'est pas lui supprimé de la mémoire?.

Si je prend l'exemple d'une TABLE sur laquelle je mets un écouteur pour ne pas avoir à gérer toutes les cases occasionne une fuite lorsque je supprime celle ci et donc par le fait tous ces enfants?.

[SylvainPV]

Si je prend l'exemple d'une TABLE sur laquelle je mets un écouteur pour ne pas avoir à gérer toutes les cases occasionne une fuite lorsque je supprime celle ci et donc par le fait tous ces enfants?.

Non pas tout à fait, avec ton exemple l'évènement sur les TD est délégué à TABLE, autrement dit le listener est rattaché à TABLE. Donc si tu supprimes TABLE, pas de fuite. Mais imaginons que tu as une Single Page Application avec un conteneur principal qui contient des "sous-vues" (dans notre cas on utilise Backbone) ; si un évènement sur une sous-vue est délégué à window, alors il faut faire attention à bien le supprimer lorsqu'on quitte cette sous-vue, car window n'est pas réinitialisé. On appelle ça les vues zombie dans le jargon Backbone. On retrouve souvent des problèmes similaires avec les plug-ins d'interface type jQuery UI qui se gavent sur les événements délégués et, dans le meilleur des cas, proposent une méthode spéciale pour se désinstancier "proprement" : http://api.jqueryui.com/jquery.widget/#method-_destroy

[Bovino]

Oui, elem=null; (voire elem=undefined;) est un bonne alternative.
A noter aussi que si elem a été défini sans le mot clé var, il est alors non pas une variable globale, mais une propriété de l'objet global window (en fait, le code JavaScript du navigateur peut être considéré comme inclus dans un with(window)) et on peut donc lui appliquer l'opérateur delete.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
var foo = 'bar';
baz = 42;
delete foo;
console.log(foo);  // 'bar'
delete baz;
console.log(baz);  // ReferenceError: baz is not defined !

Si je prend l'exemple d'une TABLE sur laquelle je mets un écouteur pour ne pas avoir à gérer toutes les cases occasionne une fuite lorsque je supprime celle ci et donc par le fait tous ces enfants?.

Non, si tu supprimes la table, alors il n'y a pas de problème. Mais tu peux poser un écouteur délégué sur un élément et supprimer uniquement ses enfants concernés par le gestionnaire sans supprimer l'élément portant effectivement le listener, c'est dans ce cas que tu peux avoir des déboires.

[adiGuba]

Mais si le code est défini dans une fonction , on n'a pas affaire à une variable globale mais à une variable locale.

Avec le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
function appendDIV() {
    var elem = document.createElement('div');
    elem.addEventListener('click', function(){
        alert('cliqué');
    });
    document.getElementById('id').appendChild(elem);
}

Lorsque le div ainsi créé est supprimé du DOM, je pense (et j'espère) qu'il est garbage-collectable.
Non ?


a++

[Bovino]

Oui rassure toi.
On allait un peu plus loin que ta demande suite aux questions de NoSmoking. Je précisais juste que contrairement à la croyance répandue, une variable définie sans le mot clé var n'est pas une variable globale mais une propriété d'objet.

Mais si ta variable est déclarée dans une fonction avec le mot clé var, il n'y a pas de souci avec le garbage collector.

[SylvainPV]

il est alors non pas une variable globale, mais une propriété de l'objet global

Euh ben justement c'est ça la définition d'une variable globale Sinon il n'y a plus aucune variable globale, vu que window est en référence circulaire directe.