Javascript discret Obfuscates Event Handling

Question

Vous savez ce que j'ai aimé le mieux à propos de javascript intrusif? Vous avez toujours su ce qu'il allait faire lorsque vous déclenchez un événement.

<a onclick="thisHappens()" /> 

Maintenant que tout le monde boit le kool-aid discret, ce n'est pas si évident. Les appels à lier des événements peuvent se produire sur n'importe quelle ligne de n'importe quel nombre de fichiers javascript inclus dans votre page. Cela peut ne pas être un problème si vous êtes le seul développeur, ou si votre équipe dispose d'une sorte de convention pour les gestionnaires d'événements contraignants, comme toujours en utilisant un certain format de classe CSS. Dans le monde réel cependant, il est difficile de comprendre votre code.

Les navigateurs DOM comme Firebug semblent pouvoir aider, mais il est encore long de parcourir toutes les propriétés du gestionnaire d'événements d'un élément pour en trouver un qui exécute le code que vous recherchez. Même alors, il vous indique simplement que c'est une fonction anonyme() sans numéro de ligne.

La technique que j'ai trouvée pour découvrir quel code JS est exécuté quand des événements sont déclenchés est d'utiliser l'outil de profilage de Safari qui peut vous dire ce que JS est exécuté dans un certain laps de temps, mais cela peut parfois JS à chasser à travers.

Il doit y avoir un moyen plus rapide de savoir ce qui se passe lorsque je clique sur un élément. Quelqu'un peut-il m'éclairer?

Answer 1

Si vous utilisez jQuery, vous pouvez profiter de son système d'événements de pointe et d'inspecter les corps des fonctions de gestionnaires d'événements attachés:

$('body').click(function(){ alert('test')}) 

var foo = $('body').data('events'); 
// you can query $.data(object, 'events') and get an object back, then see what events are attached to it. 

$.each(foo.click, function(i,o) { 
    alert(i) // guid of the event 
    alert(o) // the function definition of the event handler 
}); 

Ou vous pouvez mettre en œuvre votre propre système d'événements.

Answer 2

L'appeler «kool-aid» semble injuste. Les événements DOM niveau 2 résolvent des problèmes spécifiques avec la gestion des événements en ligne, comme les conflits qui en résultent toujours. Je ne reviens pas à l'écriture de code pour utiliser window.onload qui doit vérifier si quelqu'un d'autre l'a déjà assigné, et parfois l'avoir surchargé par accident ou par négligence. Il assure également une meilleure séparation des couches structure (HTML) et comportement (JS). Dans l'ensemble, c'est une bonne chose. En ce qui concerne le débogage, je ne pense pas qu'il existe un moyen de résoudre les gestionnaires d'événements étant des fonctions anonymes, autre que harceler les auteurs pour utiliser des fonctions nommées lorsque cela est possible. Si vous le pouvez, dites-leur que cela produit des piles d'appels plus significatives et rend le code plus facile à maintenir.

Answer 3

Découvrez Visual Event ... c'est un bookmarklet que vous pouvez utiliser pour exposer des événements sur une page.

Answer 4

Pour répondre à votre question, essayez d'utiliser la ligne de commande Firebug. Cela vous permettra d'utiliser JavaScript pour saisir rapidement un élément par un ID, puis de parcourir ses écouteurs. Souvent, si vous utilisez console.log, vous pourrez même obtenir les définitions de fonctions.

---

Maintenant, pour défendre le discret:

L'avantage que je trouve en JavaScript discret est qu'il est beaucoup plus facile pour moi de voir les DOM pour ce qu'elle est. Cela dit, je pense qu'il est généralement de créer des fonctions anonymes (à quelques exceptions près). (La plus grande faille que je trouve avec JQuery est en fait dans leur documentation: les fonctions anonymes peuvent exister dans un monde inférieur où la défaillance ne conduit pas à une sortie utile, mais JQuery les a rendues standard.J'ai généralement la politique d'utiliser uniquement des fonctions anonymes si j'ai besoin d'utiliser quelque chose comme bindAsListener de Prototype. En outre, si les fichiers JS sont correctement divisés, ils n'aborderont qu'un seul sous-ensemble du DOM à la fois. J'ai une bibliothèque "case à cocher ordonnée", il est dans seulement un fichier JS qui est ensuite réutilisé dans d'autres projets. Je disposerai aussi généralement de toutes les méthodes d'une sous-bibliothèque donnée en tant que méthodes membres d'un objet JSON ou d'une classe et j'ai un objet/classe par fichier js (comme si je faisais tout dans un langage plus formalisé). Si j'ai une question sur mon "code de validation de formulaire", je vais regarder l'objet formValidation dans formvalidation.js.

Dans le même temps, je suis d'accord que parfois les choses peuvent devenir obtus de cette façon, en particulier lorsqu'il s'agit d'autres. Mais le code désorganisé est du code désorganisé, et il est impossible de l'éviter à moins que vous ne travailliez seul et que vous soyez un bon programmeur. En fin de compte, cependant, je préférerais utiliser /* */ pour commenter la plupart des deux ou trois fichiers js pour trouver le code se conduisant mal, puis passer par le code HTML et supprimer les attributs onclick.

Answer 5

Une chose: vous ne devrait pas être capable de voir ce qui se passera dans JavaScript en regardant le code HTML. Quelle nuisance est-ce? HTML est pour la structure.

Si vous voulez vérifier quels événements sont liés à certains éléments, il y a un bookmarklet appelé événement visuel pour l'instant, et firebug 1.6 (IIRC) aura une sorte d'inspecteur d'événements.