2010-02-04 12 views

risposta

5

La funzione "live" nativa di jQuery sfrutta il bubbling degli eventi sul DOM. Il plugin "liveQuery", al contrario, usa il selettore per trovare gli elementi nel DOM e collegare direttamente i gestori di eventi.

A mio parere si è così meglio usare la funzione "live" quando possibile, perché si tratta di meno DOM traversal ecc, ad esempio, agganciando i gestori di eventi a cose durante un grande tavolo può essere di tipo-di slow con liveQuery ma non è affatto lento con "live". Potrebbero esserci alcuni problemi (con IE ovviamente) che ti costringono a usare liveQuery a volte, sebbene jQuery 1.4 abbia migliorato notevolmente "live".

modificareAggiornamento: Sep 2017

A questo punto, le versioni moderne di jQuery centralizzare registrazione gestore di eventi nel .on() API. Brevemente:

$(selector).live("event-name", handler); 

sarebbe oggi scritto con .on():

$(document).on("event-name", selector, handler); 

Il .on() API fornisce considerevolmente maggiore flessibilità rispetto al metodo lungo deprecato .live() fatto, compresa la possibilità di utilizzare qualsiasi nodo nel DOM il punto di delega (come ha fatto il vecchio .delegate()).

+0

Se la tabella è già nel documento quando viene chiamato live(), ci sarà ancora un attraversamento DOM. per esempio. $ ("td"). live() trova ancora ogni elemento td. –

+0

C'è anche '.delegate()' e questa è un'API molto più intelligente in generale. – Pointy

+0

Se "live" è nativo di jQuery e "liveQuery" è un plug-in, preferirei utilizzare "live" perché quando si tenta di eseguire l'aggiornamento a una versione più recente di jQuery, potrebbe essere un lavoro extra e problemi durante l'aggiornamento "liveQuery" e assicurandosi che tutto sia compatibile. –

1

Il plug-in liveQuery è stato creato inizialmente, quindi è stato migrato a jQuery stesso.

3

Come Pointy said, live() sfrutta il bubbling degli eventi sul DOM (delegazione di eventi). Inoltre, per ogni chiamata, jQuery chiama solo handler sull'elemento $(event.target).closest(selector), ovvero l'elemento antenato-autore corrispondente più vicino dell'evento target. E, ovviamente, live() non supporta nulla come livequery(matchedFn, unmatchedFn).

implicazioni:

  • $(selector).live() richiede ancora un attraversamento del DOM (ovviamente). Tuttavia, se si carica jQuery e si collegano i gestori live() nella testata del documento, non esiste ancora un corpo del documento da cercare. Allo stesso modo se inserisci nuovi contenuti nella pagina.
  • live() fa meno lavoro quando viene configurato - non deve allegare i gestori ad ogni elemento abbinato
  • live() fa più lavoro nella gestione di eventi - deve attraversare antenati del target dell'evento, trovando elementi che corrispondono il selettore
  • $("div").live() è diverso da $("div").livequery() come funziona solo per la più vicina div al destinatario dell'evento
  • Analogamente, $("div, p").live() è diverso da $("div").live(); $("p").live();
Problemi correlati