jQuery API文档声明我们应该使用较新的 on()函数,而不是使用较旧的(有时是不推荐的)将偶数处理程序附加到元素的方法。
根据我的理解, on()需要绑定到页面(DOM)中“当前存在”的元素。在构建网站的日子里,页面主要是动态加载(通过Ajax)并注入,这几乎迫使我们将它绑定到文档元素。
我主要使用 live()方法绑定到“ future elements ”。这对我很有用。但我不能简单地将 live()替换为较新的 on(),因为我的元素尚不存在,如果我这样做,则无效。
我可以简单地使用 $(document).on(),但我害怕它似乎会对事件传递施加巨大的开销。至少从我的文档中了解到的。
任何人都可以评论 on()功能可能带来的潜在惩罚。也许,如果有人可以评论jQuery的理由是什么,不断弃用他们的事件绑定API(在这种情况下不向后兼容)?
答案 0 :(得分:3)
嗯,他们基本上都是一样的
这是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);
}
它们基本相同,你可以通过观察它们来猜测性能差异,
总而言之,所有 3 的on()
“前辈”都注意,但称其为“继任者”
正如评论中所提到的,Rochas已经制作了一个jsPerf,它将通过在浏览器中运行测试来向您显示性能差异,
live
测试中的两个由于现在不兼容的jQuery版本而失败,但是你可以从源头看,无论如何都是一样的。 jsPerf Benchmark
答案 1 :(得分:0)
TL; DR: live
委托将选择器表达式与文档根匹配的所有元素的事件处理。这在功能上等同于$(document).on
,因此您无需通过切换到更新的API来获得或失去任何性能。
引用您的问题:
根据我的理解,on()需要绑定到一个元素 页面(DOM)中“当前存在”。在这些建筑的日子里 页面主要是动态加载的网站(通过Ajax)和 注入,这几乎迫使我们将它绑定到文档 元件。
您似乎在暗示,当您进行绑定时,页面上唯一存在的是文档,这是一个不切实际的场景。即使您的整个文档仅使用jQuery进行汇编,您仍然可以在插入后立即将委托事件处理程序绑定到动态插入的元素。
例如,请参阅this fiddle:
<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
委派更糟糕的行为。这是因为live
委托给文档根目录,这意味着在被live
使用的选择器表达式取消资格或限定之前,任何和所有事件必须一直冒泡到文档。
答案 2 :(得分:0)
以下是我发现的差异的最佳解释。阅读它你可以用.on()替换delegate()的解释 THE DIFFERENCE BETWEEN JQUERY'S .BIND(), .LIVE(), AND .DELEGATE()
从技术上讲,on()现在是实际的功能,委托推迟启用,而不推荐使用live perf测试表明.on()稍微快一些 event delegation perf
最后一个优点是存在一个.off()函数(对turbolink / pjax站点很有用)....而且输入的次数较少; - )