[英]Performance of jQuery's on() vs. it's predecessors [live(), bind(), delegate()]
jQuery API文檔指出,我們應該使用較新的on()函數,而不是將偶數處理程序附加到元素的較舊(有時不建議使用)的方法。
據我了解, on()需要綁定到頁面(DOM)中“ 當前存在 ”的元素。 在建立網站的當今時代,頁面大多是動態加載(通過Ajax)並注入的,這幾乎迫使我們將其綁定到document元素。
我主要使用live()方法來綁定“ 未來元素 ”。 這對我來說很好。 但是我不能簡單地將我的live()替換為較新的on(),因為我的元素尚不存在,如果我這樣做,那么什么都行不通。
我可以簡單地使用$(document).on()來代替,但是我擔心它似乎會給事件傳遞帶來巨大的開銷。 至少從我從他們的文檔中了解到。
任何人都可以評論on ()函數可能給我帶來的特殊損失。 可能的話,是否有人可以評論jQuery不斷淘汰其事件綁定API的合理性(在這種情況下不向后兼容)?
好吧,他們基本上都是一樣的
這是bind
<source>的來源
function (types, data, fn) {
return this.on(types, null, data, fn);
}
這是live
<source>的來源
function (types, data, fn) {
jQuery(this.context).on(types, this.selector, data, fn);
return this;
}
這是delegate
<source>的來源
function (selector, types, data, fn) {
return this.live(types, data, fn, selector);
}
它們基本上是相同的,僅通過查看它們,您就可以猜測性能差異,
總而言之, on()
所有3個 “前任”都注意到了,但稱其為“后任”
如評論中所述,Rochas制作了一個jsPerf,它將通過在瀏覽器中運行測試向您顯示性能差異,其中兩個
live
測試由於jQuery版本不兼容而失敗,但是正如您從源代碼中看到的那樣,無論如何都一樣。 jsPerf基准
TL; DR: live
將與選擇器表達式匹配的所有元素委托給文檔根進行事件處理。 這在功能上等效於$(document).on
,因此,通過切換到較新的API,您不會在性能方面獲得任何損失。
引用您的問題:
根據我的理解,on()需要綁定到頁面(DOM)中“當前存在”的元素。 在建立網站的當今時代,頁面大多是動態加載(通過Ajax)並注入的,這幾乎迫使我們將其綁定到document元素。
您似乎暗示,進行綁定時頁面上唯一存在的是文檔,這是不現實的情況。 即使使用jQuery組裝了整個文檔,也仍然可以在將它們插入后立即將委托事件處理程序綁定到要動態插入的元素。
例如,請參見以下小提琴 :
<html>
<head>
<script>
var myDynamicElement = $('<div class="dyn_el">Please click this button: <button>Click!</button></div>');
$('body').append(myDynamicElement);
myDynamicElement.on('click', 'button', function() { alert('Works!'); });
</script>
</head>
<body>
</body>
</html>
還有就是用沒有合法理由live
在on
,尤其是因為前者在內部行為相同$(document).on
。
注意:當對方的回答指出, live
在內部稱之為“它的后繼者”,但這並不意味着它們是可以互換的! live
總是比on
文檔層次結構中較低元素的on
委派表現更差。 這是因為live
委托給文檔根目錄,這意味着任何事件和所有事件都必須一直冒泡直到文檔,直到被live
所使用的選擇器表達式取消資格或限定資格為止。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.