jQuery 绑定事件的四种方式
jQuery 提供了多种绑定事件的方式,每种方式各有其特点,明白了它们之间的异同点,有助于我们在写代码的时候进行正确的选择,从而写出优雅而容易维护的代码。下面我们来看下 jQuery 中绑定事件的方式都有哪些。
jQuery中提供了四种事件监听方式,分别是bind
、live
、delegate
、on
,对应的解除监听的函数分别是unbind
、die
、undelegate
、off
。在开始看他们之前,先来声明一个例子,各函数的用法将围绕这个例子进行,html 代码如下:
<ol id="myol">
<li>列表元素1</li>
<li>列表元素2</li>
<li>列表元素3</li>
<li>列表元素4</li>
</ol>
同时再声明一个函数,用来作为监听函数,JS 代码如下:
function getHtml(){
alert(this.innerHTML);
}
bind(type,[data],function(eventObject))
bind 是使用频率较高的一种,作用就是在选择到的元素上绑定特定事件类型的监听函数,参数的含义如下:
type:事件类型,如 click、change、mouseover 等;
data:传入监听函数的参数,通过 event.data 取到。可选;
function:监听函数,可传入 event 对象,这里的 event 是 jQuery 封装的 event 对象,与原生的 event 对象有区别,使用时需要注意。
我们来瞄一眼 bind 的源码:
bind: function( types, data, fn ) {
return this.on( types, null, data, fn );
}
可以看到内部是调用了 on 方法,这个 on 是什么样的呢?稍后我们再看。先用我们上面的例子来试试:
$('#myol li').bind('click',getHtml);
bind 的特点就是会把监听器绑定到目标元素上,有一个绑一个,在页面上的元素不会动态添加的时候使用它没什么问题。但如果列表中动态增加一个“列表元素5”,点击它是没有反应的,必须再 bind 一次才行。要想不这么麻烦,我们可以使用 live。
jQuery 还有一种事件绑定的简写方式如 a.click(function(){});
、a.change(function(){});
等,它们的作用与 bind 一样,仅仅是简写而已。
live(type, [data], fn)
live 的参数和 bind 一样,它又有什么蹊跷呢,我们还是先瞄一眼源码:
live: function( types, data, fn ) {
jQuery( this.context ).on( types, this.selector, data, fn );
return this;
}
可以看到 live 方法并没有将监听器绑定到自己( this )身上,而是绑定到了 this.context
上了。这个 context 是什么东西呢?其实就是元素的限定范围,看了下面的代码就清楚了:
$('#myol li').context; //document
$('#myol li','#myol').context; //document
$('#myol li',$('#myol')[0]); //ol
通常情况下,我们都不会像第三种方式那样使用选择器,所以也就认为这个 context 通常就是 document 了,即 live 方法把监听器绑定到了 document 上了。不把监听器直接绑定在元素上,你是不是想起事件委托机制来了呢?若没有,可以点击这里回忆一下。live 正是利用了事件委托机制来完成事件的监听处理,把节点的处理委托给了 document。在监听函数中,我们可以用event.currentTarget
来获取到当前捕捉到事件的节点。下面的例子来揭晓:
$('#myol li').live('click',getHtml);
使用事件委托的优点一目了然,新添加的元素不必再绑定一次监听器。看来live这货还真不错,以后抛弃 bind 就用它了!可以吗?答案是否定的,而且是大大的否定。因为将监听器绑定到了 document 上,所以事件的处理得等待层层冒泡,直到冒泡到根节点才开始处理,在 DOM 树较深或者节点的嵌套关系很复杂时,会有意想不到的结果,根节点的负担太重了。就像四世同堂、五世同堂,甚至八世同堂(现实中不太可能,但在 HTML 中层级关系可能远比这还多),老爷子肯定记不清哪个孙子是哪个儿子的,哪个重孙又是哪个儿子的儿子的,老爷子脑子一乱,糊涂了,事情就办错了。为此,jQuery 官方已宣布在 1.7 版本开始废弃 live ,改用其他方式代替。所以我们也顺应号召,罢用此方法。
正因为 live 存在那样的缺点,所以我们就思考,既然老爷子负担那么重,可不可以别把监听器绑定在 document 上呢,绑定在就近的父级元素上不就好了。顺应正常逻辑, delegate 诞生了。
delegate(selector,type,[data],fn)
参数多了一个 selector,用来指定触发事件的目标元素,监听器将被绑定在调用此方法的元素上。看看源码:
delegate: function( selector, types, data, fn ) {
return this.on( types, selector, data, fn );
}
又是调用了 on,并且把 selector 传给了 on。看来这个 on 真的是举足轻重的东西。照样先不管它。看看示例先:
$('#myol').delegate('li','click',getHtml);
我们在例子中将监听器绑定到ol上,event.currentTarget
显示当前捕获到事件的元素是 ol。这下,我们的选择又多了一些灵活性,不单可以利用事件委托,还可以选择委托的对象。毕竟老麻烦同一个人帮忙很不好嘛。对于如何选择委托对象,还是需要一定的策略的,毕竟父级元素可以有很多。我觉得原则应该是选择最近的“稳定”元素,选择最近是因为事件可以更快的冒泡上去,能够在第一时间进行处理。所谓“稳定”是指该父级元素是一开始就在页面上的,不是动态添加上来的,而且将来也不会消失掉,这样可以保证它可以时时监控着自己的孩子。
看了这么多,你是不是迫不及待想看看这个 on 的真实面目了呢,这就来:
on(type,[selector],[data],fn)
参数与 delegate 差不多但还是有细微的差别,首先 type 与 selector 换位置了,其次 selector 变为了可选项。交换位置的原因不好查证,应该是为了让视觉上更舒服一些吧。
我们先不传 selector 来看一个例子:
$('#myol li').on('click',getHtml);
可以看到 event.currentTarget
是 li 自己,与 bind 的效果一样。至于传 selector 进去,就是跟 delegate 一样的意义了,除了参数顺序不同,其他完全一样。
终于看到 on 的真实作用了,那么,这么多的事件绑定方式,我们该如何进行选择呢?
其实这个问题是完全不必纠结的,因为你已经知道他们之间的区别了不是么?根据实际情况斟酌使用就行。不过官方有一个推荐就是尽量使用 on,因为其他方法都是内部调用 on 来完成的,直接使用 on 可以提高效率,而且你完全可以用 on 来代替其他三种写法。至于如何代替我想就不必这么直白的写出来了,真正理解它们的区别之后自然而然也就不是难事了。
转自 : jQuery绑定事件的四种方式