2009-10-06 15 views
6

¿Sabes lo que más me gustó de JavaScript obtrusivo? Siempre supo lo que iba a hacer cuando desencadenó un evento.JavaScript discreto Obfusca el manejo de eventos

<a onclick="thisHappens()" /> 

Ahora que todo el mundo está bebiendo la Kool-Aid discreto que no es tan obvio. Las llamadas a eventos vinculados pueden ocurrir en cualquier línea de cualquier cantidad de archivos javascript que se incluyan en su página. Esto podría no ser un problema si eres el único desarrollador, o si tu equipo tiene algún tipo de convención para vincular eventhandlers como siempre usando un cierto formato de clase CSS. En el mundo real, sin embargo, hace que sea difícil entender tu código.

Parece que los navegadores DOM como Firebug pueden ayudar, pero aún lleva mucho tiempo explorar todas las propiedades de controlador de eventos de un elemento solo para encontrar uno que ejecute el código que está buscando. Incluso entonces, generalmente solo te dice que es una función anónima() sin número de línea.

La técnica que he encontrado para descubrir qué código JS se ejecuta cuando se desencadenan los eventos es usar la herramienta Perfilación de Safari que puede decir qué se ejecuta JS en un determinado período de tiempo, pero a veces puede ser una gran cantidad de JS para cazar

Tiene que haber una forma más rápida de descubrir qué sucede cuando hago clic en un elemento. ¿Alguien puede por favor iluminarme?

+0

Estaría muy interesado en eso, también. :) – arno

+0

Encontré esta pregunta http://stackoverflow.com/questions/446892/how-to-find-event-listeners-on-a-dom-node/447106#447106 – arkanciscan

Respuesta

4

Si está utilizando jQuery se puede tomar ventaja de su sistema de avanzada de eventos e inspeccionar los cuerpos de las funciones de los controladores de eventos adjuntos:

$('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 
}); 

O se podría implementar su propio sistema de eventos.

+0

Eso es bastante limpio. – slikts

1

Llamarlo "kool-aid" parece injusto. Los eventos DOM Nivel 2 resuelven problemas específicos con el manejo de eventos en línea, como los conflictos que siempre resultan. No miro hacia atrás para escribir código para usar window.onload que tiene que verificar si alguien más lo ha asignado antes, y algunas veces tenerlo anulado por accidente o por descuido. También asegura una mejor separación de las capas de estructura (HTML) y comportamiento (JS). En general, es algo bueno.

En cuanto a la depuración, no creo que haya ninguna forma de resolver que los manejadores de eventos sean funciones anónimas, aparte de molestar a los autores para que usen funciones nombradas cuando sea posible. Si puede, dígales que produce pilas de llamadas más significativas y hace que el código sea más fácil de mantener.

8

Check out Visual Event ... es un bookmarklet que puede usar para exponer eventos en una página.

2

Para responder a su pregunta, intente utilizar la línea de comando de Firebug. Esto le permitirá usar JavaScript para tomar rápidamente un elemento mediante una ID, y luego iterar a través de sus oyentes. A menudo, si se utiliza con console.log, incluso podrá obtener las definiciones de funciones.


Ahora, para defender la discreta:

La ventaja que encuentro en Javascript no intrusivo es que es mucho más fácil para mí ver el DOM para lo que es. Dicho esto, creo que generalmente es mala práctica crear funciones anónimas (con solo algunas excepciones). (La falla más grande que encuentro con JQuery está realmente en su documentación. Las funciones anónimas pueden existir en un mundo inferior donde la falla no conduce a resultados útiles, pero JQuery las ha convertido en estándar.) En general, tengo la política de usar solo funciones anónimas si necesito usar algo como bindAsListener de Prototype.

Además, si los archivos JS están divididos correctamente, solo se dirigirán a un subconjunto del DOM a la vez. Tengo una biblioteca de "casilla de verificación ordenada", está en solo un archivo JS que luego se vuelve a usar en otros proyectos. También tendré generalmente todos los métodos de una sub biblioteca dada como métodos miembros de un objeto JSON o una clase y tengo un objeto/clase por archivo js (como si estuviera haciendo todo en un lenguaje más formalizado) Si tengo una pregunta sobre mi "código de validación de formulario", miraré el objeto formValidation en formvalidation.js.

Al mismo tiempo, estoy de acuerdo en que a veces las cosas pueden volverse obtusas de esta manera, especialmente cuando se trata de otros. Pero el código desorganizado es un código desorganizado, y es imposible evitarlo a menos que trabaje solo y sea un buen programador.

Al final, prefiero tratar con el uso de /* */ para comentar la mayoría de los dos o tres archivos js para encontrar el código que funciona mal, luego ir a través del HTML y eliminar los atributos onclick.

1

Una cosa: no debería ver qué pasará en JavaScript mirando el código HTML. ¿Qué molestia es eso? HTML es para la estructura

Si desea comprobar qué eventos están ligados a ciertos elementos, hay un bookmarklet llamado evento visual por ahora, y firebug 1.6 (IIRC) tendrá algún tipo de inspector de eventos.

Cuestiones relacionadas