¿Qué pasa con el método jQuery Live?

Question

El método live() está en desuso en jQuery 1.7. Los documentos jQuery ahora recomiendan

Utilice .on() para adjuntar controladores de eventos. Los usuarios de versiones anteriores de jQuery deben usar .delegate() con preferencia a .live().

entiendo cómo on y delegate trabajo, pero no entiendo por qué son mejores. live() es más simple y fácil de usar.

¿Hay alguna razón por la que live haya quedado obsoleto? ¿Cómo son los otros métodos mejores? ¿Va a pasar algo malo si continúo usando live?

Answer 1

Vea algunas de las explicaciones aquí:

http://www.ultimatewebtips.com/why-jquery-live-is-a-bad-option-to-use/ (sitio parece estar abajo)

Cita:

1. No puede utilizar .live() para widgets reutilizables.

2. .stopPropagation() no funciona con directo.

3. .live() es más lento.

4. .live() no se puede encadenar.

Además belleza de .on() es que optimiza todos los eventos bastante bien: http://api.jquery.com/on/

D'uh que saben sobre el enlace de la API y ver cómo funciona :) .on()

Cita:

El método .on() asocia el controlador de eventos s al conjunto actualmente seleccionado de elementos en el objeto jQuery. A partir de jQuery 1.7, el método .on() proporciona toda la funcionalidad necesaria para adjuntar manejadores de eventos. Para ayuda en la conversión desde métodos de evento jQuery más antiguos, consulte .bind(), .delegate() y .live(). Para eliminar eventos enlazados con .on(), vea .off(). Para adjuntar un evento que se ejecuta sólo una vez y luego elimina en sí, ver .one()

Answer 2

Estoy bastante seguro de que esto se debe a la naturaleza de .live(). Es conveniente y todo, pero es una mala práctica usarlo ya que obliga a su navegador a buscar en la mayoría de los casos más eventos que los requeridos.

En lugar de buscar de forma predeterminada todos los documentos para un determinado evento, es más eficiente en datos buscar en un contenedor específico.

live() de hecho fue conveniente, y la mayoría de los usuarios nunca notaron ningún defecto al usarlo. Era básicamente una mejora bind() en mis ojos.

Pero en muchas ocasiones tenemos que adaptarnos y ser más claros con nuestro código sobre lo que se debe ejecutar.

Es como preguntarse por qué tiene que importar cosas, y por qué no todo se importa al inicio.

Answer 3

live() concede los controladores al objeto documento, que básicamente se traduce en la interceptación todos los eventos de la clase dada, incurrir en el costo para una búsqueda de elementos que coincidan con el selector. con delegate() y on(), se recomienda adjuntar datos más cercanos a los objetivos esperados (en su elemento primario directo, si es posible), lo que reduce el número de eventos gestionados y, respectivamente, busca objetivos coincidentes.

Answer 4

Aquí hay un detallado article by Paul Irish sobre el rendimiento en vivo() y los límites.

Si continúa utilizando live, su código ya no funcionará más adelante si actualiza la biblioteca jQuery en sus proyectos.

Answer 5

$('some selector').live(' ... ', handler)

es lo mismo que

$(document).on(' ... ', 'some selector', handler)

Así que cuando se utiliza live en realidad se asigna a todos los manejadores de la raíz de su árbol DOM. Hay dos desventajas para eso:

1. La vinculación de los manejadores a la raíz DOM aumenta la ruta que el evento debe atravesar mientras se inicia. Eso impactaría el rendimiento de una mala manera.
2. Existe un mayor riesgo de que algún otro controlador con return false al final evite que el controlador live se dispare.

Answer 6

live() es ineficiente por dos razones:

• En el constructo $('selector').live(), jQuery primero tiene que seleccionar todos los elementos. Sin embargo, al llamar al live(), solo necesita el selector del objeto jQuery (almacenado en .selector) y no utiliza ninguno de los elementos seleccionados. Por lo tanto, es un poco derrochador seleccionar primero todos los elementos coincidentes y luego no usarlos.on() y delegate() tome el selector de destino como parámetro lo que significa que no se seleccionan elementos de destino de antemano y la prueba se produce solo cuando se desencadena el evento.
• live() por defecto está limitado al nivel document, por lo tanto, todos los eventos deben aparecer en todo el DOM. Usted puede limitarlo especificando un contexto con $(selector, context).live(), pero es mejor usar on() o delegate() para esto.

Al escribir nuevo código, se recomienda encarecidamente el uso de la última y mejor on() en lugar de delegate() y el desuso live(). Sin embargo, no creo que el soporte para live() se elimine en el corto plazo (si es que lo hace), ya que muchos scripts dependen de él. Además, no hay ninguna desventaja real de usar live() sobre on(), como en la propia fuente de jQuery live() se define como:

live: function(types, data, fn) { 
    jQuery(this.context).on(types, this.selector, data, fn); 
    return this; 
} 

Answer 7

Hay dos problemas principales con el live método:

1. que concede todos manejadores de eventos en el nivel del documento, por lo que cualquier evento que aparezca en el documento debe coincidir con los tipos de eventos y selectores para todos los eventos en vivo. Si tiene muchos eventos, la página será lenta. Debe usar delegate o on para limitar el alcance de donde verifica los eventos.

2. El uso del método no es típico de cómo se usan selectores con otros métodos en la biblioteca. Solo puede usarlo en objetos jQuery creados con un selector. Los métodos delegate y on lo hacen natural al suministrar el selector al método.