对于独特的dom元素,总是使用live()而不是bind()的缺点?

时间:2010-10-20 19:56:05

标签: javascript dom jquery

编写jQuery绑定事件时,我通常使用bind()别名(click()submit()等)。

但是,我使用动态生成的内容的次数越多,我发现bind()何时不起作用就越不明确,最后调试半小时直到我尝试live()并且它作品。

在ID选择器的参数范围内(例如“#foo”,而不是.classes或元素('input')):

除了缺少方便的别名之外,对于这些类型的绑定总是使用live()而不是bind()是否有任何缺点,因为只有一个DOM元素与特定ID绑定?

===========

编辑:我询问bind()live()之间的区别是什么;这已被覆盖。我问的是,默认情况下使用live()有什么缺点,因为诱惑是在你不能错误地选择的情况下(即当你使用#uniqueDomElement时)这样做,以及避免考虑bind()何时不合适。

3 个答案:

答案 0 :(得分:3)

.live()的主要缺点是权重(这适用于使用大量.live()处理程序时),因为它默认情况下将事件处理程序附加到document和事件 在那里冒泡(它的工作原理的整个基础),这意味着当事件到达文档时,必须检查一些事情:

  • 此事件类型是否有.live()个事件?
  • 如果我这样做,事件来自的元素是否匹配那些.live()处理程序的任何选择器?

第一个很便宜,第二个不是。我们来看一个最常见的例子click事件。一个click事件泡沫,到目前为止一直很好。假设我们在click注册document时有一个或多个.live()事件处理程序...现在我们必须遍历这些处理程序的所有并比较它们事件来自的元素的选择器,您拥有的处理程序越多,获得的成本就越高,并且每次点击都会发生,这是迄今为止最大的性能损失{ {3}}

还有其他问题,例如附加/删除处理程序,但这是对处理程序的管理......当你有大量处理程序时,上述性能问题是将它与直接比较时的主要问题.live()致电。

答案 1 :(得分:0)

你遇到的问题是你必须在元素出现在页面上之后调用bind。通常人们会在文档就绪上调用bind,以便他们可以将行为附加到页面上的元素。如果在之后通过javascript将一个元素添加到页面中,则需要对添加的新元素应用相同的绑定调用,这通常很麻烦,因此您可以使用.live。

.live使用事件委托,这意味着jquery不是将一个函数处理程序绑定到页面上的特定元素,而是管理所有不同的实时调用,这样当你进行某种实际处理程序的操作时,它将会检查你执行该操作的元素是否与给定的选择器匹配(我相信这是它的工作原理)。我的猜测是它将事件添加到文档正文(用于点击/鼠标操作).. 我不确定具体细节,但我知道,如果你把它用于所有东西,你可以通过现场获得一些奇怪的行为。通常最好使用如果你有大量的元素,你将应用某些行为或如果你将通过javascript动态添加这些元素。

阅读文档了解更多信息:http://api.jquery.com/live/

答案 2 :(得分:0)

这是一种平衡行为。 Live()将事件绑定到文档并搜索已触发的事件目标。生存的优点(即事件委托,通常)是您只为一个无限数量的参数绑定一个事件处理程序。 Bind()将事件处理程序直接附加到元素本身,因此如果表中有1,000行,并且运行$('tr').bind(...),则将绑定1,000个事件处理程序。如果你做了$('tr').live(...)那么你只需绑定一个事件处理程序。

你可以通过使用.delegate()在中间见面,它与live不同,因为你指定了事件的上下文。因此,它不会总是火,因此更有效。使用表格示例,您将使用$('table').delegate('tr', 'click', function() { .... });。你可以获得绑定和实时的优点:最小的缺点:你绑定1个事件处理程序,它的未来证明(只有那个表的上下文),你不横向整个dom寻找'tr'元素。

Bind,live和delegate都有自己的位置。

另外,在旁注中,委托只是另一种方式来做$('tr',$('table')[0])。live(),但看起来很难看,因此委托存在。