Introduction to four ways to bind events with jQuery

jQuery provides a variety of ways to bind events. Each method has its own characteristics. Understanding the similarities and differences between them will help us make the right choice when writing code, so as to write elegant and easy to maintain code. Let's take a look at the ways to bind events in jQuery.

jQuery provides four event monitoring methods, namely bind, live, delegate, and on. The corresponding functions to unlisten are unbind, die, undelegate, and off. Before starting to look at them

One: bind(type,[data],function(eventObject))

bind is the more frequently used one. Its function is to bind a listening function of a specific event type to the selected element. , the meaning of the parameters is as follows:

type: event type, such as click, change, mouseover, etc.;

data: parameters passed into the listening function, obtained through event.data. Optional;

function: listening function, which can pass in the event object. The event here is the event object encapsulated by jQuery, which is different from the native event object. When using it, you need to pay attention to the source code of

bind:

bind: function( types, data, fn ) {
return this.on( types, null, data, fn );
}
$('#myol li').bind('click',getHtml);

The characteristic of bind is that it will bind the listener to the target element, one to one. There is no problem in using it when the elements on the page will not be added dynamically. But if a "list element 5" is dynamically added to the list, there will be no response when clicking on it, and you must bind it again. To avoid this trouble, we can use live.

jQuery also has an abbreviation for event binding, such as a.click(function(){});, a.change(function(){});, etc. Their functions are the same as bind, they are just abbreviations.

Two: live(type, [data], fn)

The parameters of live are the same as bind. What’s wrong with it? Let’s take a look at the source code first:

live: function( types, data, fn ) {
jQuery( this.context ).on( types, this.selector, data, fn );
return this;
}

You can see the live method and The listener is not bound to itself (this), but to this.context. What is this context? In fact, it is the limited range of the element. It will be clear after reading the following code:

$('#myol li').context; //document
$('#myol li','#myol').context; //document
$('#myol li',$('#myol')[0]); //ol

Normally, we do not use selectors like the third method, so It is considered that this context is usually the document, that is, the live method binds the listener to the document. Without binding the listener directly to the element, have you remembered the event delegation mechanism? If not, you can click here to recall it. Live uses the event delegation mechanism to complete event monitoring and processing, and delegates node processing to document. In the listening function, we can use event.currentTarget to obtain the node currently capturing the event. The following example will reveal:

$('#myol li').live('click',getHtml);

Three: Live has such shortcomings, so we thought, since the old man has such a heavy burden, can we not bind the listener to the document, but bind it to the nearest one? It would be better if it were on the parent element. Following normal logic, delegate was born.

The parameter has an additional selector, which is used to specify the target element that triggers the event. The listener will be bound to the element that calls this method. Take a look at the source code:

delegate: function( selector, types, data, fn ) {
return this.on( types, selector, data, fn );
}

called on again and passed the selector to on. It seems that this on is really important. Just ignore it for now. Let’s take a look at the example first:

$('#myol').delegate('li','click',getHtml);

After reading so much, you can’t wait to see the true face of this on. Here it comes:

on(type,[selector],[data],fn)

The parameters are similar to those of delegate but there are still some The subtle difference is that first, type and selector have changed their positions, and second, selector has become optional. The reason for switching positions is difficult to verify, but it should be to make it more visually comfortable.

Let’s look at an example without passing the selector:

$('#myol li').on('click',getHtml);

You can see that event.currentTarget is li itself, which has the same effect as bind. As for passing the selector in, it has the same meaning as the delegate. Except for the different order of parameters, everything else is exactly the same.

Finally we see the real role of on. So, with so many event binding methods, how should we choose?

In fact, there is no need to worry about this issue at all, because you already know the difference between them, right? What? Just use it according to the actual situation. However, an official recommendation is to use on as much as possible, because other methods are completed by calling on internally. Using on directly can improve efficiency, and you can use on to replace the other three writing methods. As for how to replace them, I think there is no need to write them out so straightforwardly. After truly understanding their differences, it will naturally not be difficult.