subscripción
Koalite's blog
EventHandlers con jQuery 1.7: on() vs click()
Enero 19th, 2012 - [Enlace local]
En la última versión de jQuery han intentado unificar las APIs de manejo de eventos en los métodos on y off. Estos métodos sustituyen a los antiguos bind(), delegate() y live().
Si comparamos el uso de on() con el de atajos que ya existían, como click(), tenemos el siguiente código:
// Asignar un manejador de eventos usando click
$("#header a").click(function() {
// manejar el evento
});
// Asignar un manejador de eventos usando on
$("#header a").on("click", function() {
// manejar el evento
});
Estas dos construcciones son equivalentes, pero on() permite hacer muchas más cosas. Una de las cosas que más me gusta es que permite usar un mismo manejador de eventos para múltiples elementos html suscribiendo el manejador a un elemento padre. Para ver lo que significa este lío de frase, es mejor ver un ejemplo. Supongamos que tenemos este código:
Si por algún oscuro motivo queremos asignar el mismo manejador de eventos a todos los elementos , podemos hacerlo de la siguiente forma:
$("#content").click("click", "a", function() {
// manejar el evento
// $(this) apunta al que ha generado el evento
});
Esto tiene varias ventajas:
- Sólo se crea una única función, independientemente del número de elementos
que tengamos, reduciendo el consumo de recursos. - Es válido para elementos que no existen todavía. Si apareciese un nuevo elemento
dentro del, automáticamente estaríamos manejando su eventoclick. Esto es especialmente útil cuando generamos html dinámicamente.Nota para los que usamos demasiado C#
Si, al igual que yo, usas mucho C# u otro lenguaje estático, es posible que se te haga raro este tipo de API. En C#, la diferencia entre usar un API como
element.click()y otra comoelement.on("click",...)es que la primera es type-safe y refactor-friendly, mientas que la segunda se basa en el uso de un magic string.Sin embargo, no hay que olvidarse que esto es Javascript y es dinámico. Es igual de “seguro” (o inseguro, según se mire), escribir
person.namequeperson["name"], por lo que el uso de magic strings es algo normal, frecuente y que hay que ver como una característica del lenguaje de la que aprovecharnos, no como una limitación.
Compartir enlace:
Posts relacionados: