Where this is coming from
When I first learned jQuery, I normally attached events like this:
$('.my-widget a').click(function() {
$(this).toggleClass('active');
});
After learning more about selector speed and event delegation, I read in several places that "jQuery event delegation will make your code faster." So I started to write code like this:
$('.my-widget').on('click','a',function() {
$(this).toggleClass('active');
});
This was also the recommended way to replicate the behavior of the deprecated .live() event. Which is important to me since a lot of my sites dynamically add/remove widgets all the time. The above doesn't behave exactly like .live() though, since only elements added to the already existing container '.my-widget' will get the behavior. If I dynamically add another block of html after that code has ran, those elements will not get the events bound to them. Like this:
setTimeout(function() {
$('body').append('<div class="my-widget"><a>Click does nothing</a></div>');
}, 1000);
What I want to achieve:
- the old behavior of .live() // meaning attaching events to not yet existent elements
- the benefits of .on()
- fastest performance to bind events
- Simple way to manage events
I now attach all events like this:
$(document).on('click.my-widget-namespace', '.my-widget a', function() {
$(this).toggleClass('active');
});
Which seems to meet all my goals. (Yes it's slower in IE for some reason, no idea why?)
It's fast because only a single event is tied to a singular element and the secondary selector is only evaluated when the event occurs (please correct me if this is wrong here). The namespace is awesome since it makes it easier to toggle the event listener.
My Solution/Question
So I'm starting to think that jQuery events should always be bound to $(document).
Is there any reason why you would not want to do this?
Could this be considered a best practice? If not, why?
If you've read this whole thing, thank you. I appreciate any/all feedback/insights.
Assumptions:
- Using jQuery that supports
.on()
// at least version 1.7 - You want the the event to be added to dynamically added content
Readings/Examples:
Event delegation is a technique to write your handlers before the element actually exist in DOM. This method has its own disadvantages and should be used only if you have such requirements.
When should you use event delegation?
Why you should not use event delegation?
PS: Even for dynamic contents you don't have to use event delegation method if you are bind the handler after the contents get inserted into DOM. (If the dynamic content be added not frequently removed/re-added)
No - you should NOT bind all delegated event handlers to the
document
object. That is probably the worst performing scenario you could create.First off, event delegation does not always make your code faster. In some cases, it's is advantageous and in some cases not. You should use event delegation when you actually need event delegation and when you benefit from it. Otherwise, you should bind event handlers directly to the objects where the event happens as this will generally be more efficient.
Second off, you should NOT bind all delegated events at the document level. This is exactly why
.live()
was deprecated because this is very inefficient when you have lots of events bound this way. For delegated event handling it is MUCH more efficient to bind them to the closest parent that is not dynamic.Third off, not all events work or all problems can be solved with delegation. For example, if you want to intercept key events on an input control and block invalid keys from being entered into the input control, you cannot do that with delegated event handling because by the time the event bubbles up to the delegated handler, it has already been processed by the input control and it's too late to influence that behavior.
Here are times when event delegation is required or advantageous:
To understand this a little more, one needs to understand how jQuery delegated event handlers work. When you call something like this:
It installs a generic jQuery event handler on the
#myParent
object. When a click event bubbles up to this delegated event handler, jQuery has to go through the list of delegated event handlers attached to this object and see if the originating element for the event matches any of the selectors in the delegated event handlers.Because selectors can be fairly involved, this means that jQuery has to parse each selector and then compare it to the characteristics of the original event target to see if it matches each selector. This is not a cheap operation. It's no big deal if there is only one of them, but if you put all your selectors on the document object and there were hundreds of selectors to compare to every single bubbled event, this can seriously start to hobble event handling performance.
For this reason, you want to set up your delegated event handlers so a delegated event handler is as close to the target object as practical. This means that fewer events will bubble through each delegated event handler, thus improving the performance. Putting all delegated events on the document object is the worst possible performance because all bubbled events have to go through all delegated event handlers and get evaluated against all possible delegated event selectors. This is exactly why
.live()
is deprecated because this is what.live()
did and it proved to be very inefficient.So, to achieve optimized performance: