...
...
...
Attributs HTML onclick vs addEventListener : quelle approche choisir ?
La première chose qui claque : onclick écrase tout. Si tu poses deux handlers onclick sur le même élément, seul le dernier survive. C'est un problème dès que tu veux séparer les responsabilités ou que tu utilises des bibliothèques qui posent leurs propres écouteurs. addEventListener, lui, empile les listeners sans conflit.
En plus, addEventListener te donne le contrôle sur la propagation (capture/bubbling) et te permet de retirer un listener spécifique avec removeEventListener. Franchement, une fois que tu as goûté à ça, tu ne reviens pas à onclick. Mon conseil : adopte addEventListener systématiquement pour le code JavaScript, et laisse onclick uniquement pour les prototypes ou les démos rapides.
Comprendre la propagation des événements : bubbling et capturing
Si tu crois qu'un clic ne concerne que l'élément cliqué, détrompe-toi. L'événement voyage en trois phases : capture (depuis la racine vers la cible), target, puis bubbling (remontée). Le mode par défaut des écouteurs est le bubbling. Avec le troisième paramètre true d'addEventListener, tu actives la capture. C'est puissant, mais aussi source de bugs si tu ignores ce mécanisme.
Pour arrêter la propagation, tu as stopPropagation(). Mais utilise-le avec parcimonie : ça peut briser des comportements comme la délégation. Ma pratique perso : je préfère laisser la propagation naturelle et attacher un seul écouteur sur le parent, en filtrant avec e.target.matches(). Ainsi, un seul listener gère tous les enfants, même ceux ajoutés dynamiquement. C'est plus propre et plus performant.
Triggers SQL : pièges et bonnes pratiques
Le piège numéro un des triggers SQL, c'est l'effet de bord invisible. Tu poses un AFTER UPDATE, et soudain des performances dégradées sans comprendre pourquoi. Le trigger s'exécute silencieusement, hors de ton code applicatif. Résultat : tu passes des heures à debugger ce que le trigger fait dans ton dos.
Pour les contrôler, garde-les simples. Un trigger ne devrait jamais exécuter une requête lourde ou appeler une procédure complexe. Si tu as besoin de logique métier coûteuse, déporte-la dans l'application. J'ai déjà vu un trigger lancer un calcul de statistiques à chaque insertion : la table était bloquée plusieurs secondes. Insupportable.
et dans le trigger tu vérifies cette variable avant d'agir. Les triggers INSTEAD OF sont aussi une bonne alternative : ils te donnent le contrôle total sur l'opération sans les surprises des triggers AFTER ou BEFORE. Ma pratique perso : je n'utilise les triggers que pour des audits simples ou des contraintes qui ne peuvent pas être gérées ailleurs. Tout le reste, je le gère dans l'application.
Optimiser la gestion des événements fréquents : debouncing, throttling et plus
Tu crois maîtriser le scroll ? Détrompe-toi. Un listener brut sur scroll peut déclencher 60 fois par seconde des calculs lourds. Résultat : ta UI devient laggy, l'utilisateur subit un défilement saccadé. J'ai vu trop de sites planter pour ça. La solution ? Deux techniques simples mais diablement efficaces : le debouncing et le throttling.
Tu vois ? Tant que l'utilisateur tape, le timer est réinitialisé. Pas de requête inutile.
Ici, updatePosition ne sera pas appelée plus d'une fois toutes les 100ms. C'est suffisant pour rafraîchir une UI sans la faire hoqueter.
Alors, debounce ou throttle ? Ma règle empirique : si tu veux attendre la fin d'une action (frappe, redimensionnement), choisis debounce. Si tu veux espacer des appels continus (scroll, mousemove), prends throttle. Mais ne les confonds pas : un throttle ne retarde pas, il échantillonne. Un debounce retarde jusqu'à la fin du silence.
Tu veux aller plus loin ? Pour les animations, préfère requestAnimationFrame à throttle. Le navigateur sait mieux que toi quand lancer les mises à jour visuelles. Combiner debounce et requestAnimationFrame peut donner des trucs très propres.
Conclusion
Un fait marquant : dans mon expérience, 80% des bugs liés aux événements viennent d'une méconnaissance de la propagation. Les triggers SQL, eux, plombent les performances sans que personne ne s'en rende compte. Tu l'as vu avec les exemples concrets.
Alors concrètement : pour le DOM, addEventListener est ton ami, maîtrise le bubbling et la capture, et n'oublie pas de retirer tes écouteurs pour éviter les fuites mémoire. Pour les triggers SQL, pose-les en BEFORE pour les validations, et en AFTER uniquement pour des actions légères et asynchrones. Un trigger qui fait une jointure lourde, c'est une bombe à retardement.
En bref, la clé c'est la conscience de ces mécanismes sous-jacents. Avec ces réflexes, tu construiras des applications robustes, sans mauvaises surprises.