Les frameworks JavaScript offrent tellement de fonctionnalités qu’il est facile d’y tomber si vous n’y faites pas attention. Plus vous comptez sur les bibliothèques d'outils, un petit changement lors d'une modification ou d'une maintenance est susceptible d'affecter d'autres fonctions (communément appelé il y a des mines partout, vous devez donc être prudent lorsque vous marchez), en particulier lors de la maintenance du code existant il y a de nombreuses années. Une erreur que je vois souvent concerne les déclencheurs de jQuery, qui permettent aux développeurs de déclencher manuellement certains événements. Cette fonction est vraiment puissante et facile à utiliser, mais veuillez respecter la convention et ne déclenchez pas ces noms d'événements natifs dans JS
Remarque : je sais que d'autres frameworks JS fournissent également cette fonction - j'utilise uniquement jQuery à titre d'exemple ! , parce que j'ai vu sa popularité et que j'ai rencontré ce problème récemment. Toutes les bibliothèques d'outils peuvent provoquer le même problème. Par exemple, MooTools utilise fireEvent, etc.
Ce qui suit est un exemple typique d'utilisation d'un déclencheur pour effectuer une tâche :
// Écouter les événements de clic
jQuery('.tabs a').on('click', function() {
// Effectuer certaines opérations, telles que changer d'interface , chargement de contenu, etc.
});
// Déclencher l'événement click sur la dernière balise a
jQuery('.tabs a').last().trigger('click' );
Le code ci-dessus ouvrira la balise tab de l'index donné. Je comprends parfaitement pourquoi les développeurs utilisent des déclencheurs pour gérer ces choses, généralement parce que la fonction à déclencher n'est pas disponible globalement, alors que déclencher un événement est facile et toujours disponible. Le problème est que l'utilisation de noms d'événements natifs pour déclencher peut... déclencher... des dommages indescriptibles. Jetons un coup d'oeil au contenu ajouté ailleurs sur le site :
// Écoutez tous les événements de clic à l'intérieur du corps
jQuery('body').on('click', 'a', function() {
// Certains traitements de logique métier peuvent être effectuée ici.. .
// Si la condition remplie (Condition remplie) est remplie, effectuez d'autres opérations !
if(conditionMet) {
// Rafraîchir la page
// Ouvrir le sous-menu ?
// Soumettre le formulaire ?
// ... Deng Deng Deng, Intel
}
}
Maintenant, il y a un problème. - L'événement de clic d'onglet peut être surveillé par d'autres parties complètement indépendantes, ce qui rend sa gestion plus difficile. Haha, la meilleure solution est d'utiliser un nom d'événement personnalisé à la suite de l'événement natif :
// Lorsque vous écoutez des événements de clic, apportez des événements personnalisés
jQuery('.tabs a').on('click tabs-click', function() {
// Changer d'onglet, charger du contenu, etc...
});
// Déclencher un "faux" événement sur le dernier onglet
jQuery('.tabs a' ).last().trigger (« onglets-clic »);
Désormais, votre déclencheur d'événement n'entrera plus en conflit avec les autres auditeurs de la page. Les développeurs conservateurs me disent que vous voudrez peut-être éviter d'utiliser le déclencheur (comme avec d'autres bibliothèques), mais vous devriez quand même ajouter un nom d'événement personnalisé !