Expliquez la délégation d'événements et quand vous l'utiliseriez plutôt que d'attacher des écouteurs à chaque élément.

La délégation d'événements consiste à attacher un seul écouteur à un ancêtre commun et à utiliser event.target pour déterminer quel descendant a été manipulé. Ça marche parce que la plupart des événements remontent depuis la cible à travers ses ancêtres. Utilisez-la pour des listes qui changent souvent ou qui sont grandes, puisque vous évitez d'attacher et de nettoyer des centaines d'écouteurs. Évitez-la pour les événements qui ne remontent pas, comme focus, blur et la plupart des événements média.

Au lieu de mettre un écouteur de clic sur chaque ligne, j'en mets un sur le conteneur et je lis event.target, puis je remonte avec closest pour trouver la ligne qui m'intéresse. Ça marche parce que le clic remonte depuis ce qui a réellement été cliqué à travers ses ancêtres, donc le conteneur voit tout ce qui est en dessous. Les deux gains, c'est que je ne crée ni ne détruis des centaines d'écouteurs, et que les lignes ajoutées ensuite fonctionnent sans réattachement. Les pièges valent la peine d'être dits : focus et blur ne remontent pas, donc j'utilise focusin et focusout pour ceux-là, et si un bout de code entre la cible et mon conteneur appelle stopPropagation mon gestionnaire cesse silencieusement de se déclencher, ce qui est un bug vraiment pénible à traquer. Je suis surtout tombé là-dessus dans un tableau où un composant interne stoppait la propagation pour fermer son propre menu et tuait discrètement la sélection de ligne. Aujourd'hui j'ai en général la délégation gratuitement via le framework, mais je l'utilise encore directement pour les grandes listes virtualisées et tout ce qui est rendu hors de l'arbre du framework.