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:
<div id="content">
<a href="#">enlace1</a>
<a href="#">enlace2</a>
<a href="#">enlace2</a>
</div>
Si por algún oscuro motivo queremos asignar el mismo manejador de eventos a todos los elementos <a>, podemos hacerlo de la siguiente forma:
$("#content").on("click", "a", function() {
// manejar el evento
// $(this) apunta al <a> que ha generado el evento
});
Esto tiene varias ventajas:
- Sólo se crea una única función, independientemente del número de elementos
<a>que tengamos, reduciendo el consumo de recursos. - Es válido para elementos que no existen todavía. Si apareciese un nuevo elemento
<a>dentro del<div>, 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 como element.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.name que person["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.
Hola me parece que en el ejemplo que supuestamente demuestras la ventaja de usar el método on te has confundido y sigues usando el método click.
Al margen de esto, chevere la acotación del uso de este nuevo método, no lo conocía.
Saludos y gracias por el post
Creo que quieres decir «.on()» allí.
En otro tema, no me gusta «.click()», porque ese modelo requiere un nuevo método para cada nombre de cada evento. Dado que los nombres son cadenas en las definiciones del W3C de todos modos, este es un desperdicio.
Ops, se me había pasado, gracias a los 2.
@Dave, nunca lo había pensado así. Supongo que, al estar acostumbrado a C#, tener un API que no requiere strings me parece más fácil y «discoverable» porque el intellisense de Visual Studio te muestra todo lo que puedes hacer con el objeto al teclear el «.», pero en el caso de un lenguaje dinámico esto ya no tiene tanto sentido.