14

I'd like a jQuery expert in their own words to explain why the $(document) identifier is recommended by others for jQuery's on() statement vs just using an element itself

Example 1: Why is using $(document) here better then Example #2?

$(document).on("click", ".areaCodeList a", function(){
    // do stuff
});

Example 2: Why is using the element this way considering not good practice compared to Example 1?

$(".areaCodeList a").on("click", function(){
    // do stuff
});
CAbbott
  • 8,078
  • 4
  • 31
  • 38
Downpour046
  • 1,661
  • 9
  • 14
  • 5
    Where is it recommended by others? – Dirk Diggler Feb 23 '12 at 18:32
  • Who says its recommended to do it like Example 1? I've heard the contrary, that binding directly to the child element performs better than applying events to the dom. – shanabus Feb 23 '12 at 18:33
  • Please read the [docs](http://api.jquery.com/on/) I added to my answer. Learn the subject in depth. – gdoron Feb 23 '12 at 18:39
  • 1
    Do not use $(document) unless you really mean it - this is the equivalent to using .live() ... instead bind the event to the closest ancestor container to the elements that you are trying to listen to. – John Strickler Feb 23 '12 at 19:36

6 Answers6

18

Both of those are valid.

The former works for dynamically added elements. You use document because you're delegating events on children of the document object, so events bubble up to the document level. It's also more convenient to select the closest parent you can (and the parent must exist on the page at load).

The latter still works, and is a preferred way to simply bind events to specific elements.

I personally don't recommend delegating through the document object, but rather the closest parent that exists on page load.

Here are the docs for on().

Purag
  • 16,941
  • 4
  • 54
  • 75
  • So, would you say you don't recommend delegating events to the document level, and instead, the parent level? Did I understand you correctly? – Downpour046 Feb 23 '12 at 18:43
  • 2
    Yes. People use `document` when they have little understanding of the function. I would definitely recommend delegating through the closest parent. Keep in mind, the parent *must* exist on page load. But that's only for delegating to dynamic elements. If you just want to bind, select the element you want to bind to and do it the first way. – Purag Feb 23 '12 at 18:44
8

This is not true.

Those two lines do totally two different things.

The first one is a delegate event with the selector of ".areaCodeList a" while the second line is an event attached to the ".areaCodeList a" elements.

A delegate event will fire to every ".areaCodeList a" element although it was in the DOM when that line executed.

Anyway, attaching delegate events to the document isn't recommended at all. as written in the live docs:

Since all .live() events are attached at the document element, events take the longest and slowest possible path before they are handled

Please read the on docs:

Event handlers are bound only to the currently selected elements; they must exist on the page at the time your code makes the call to .on(). To ensure the elements are present and can be selected, perform event binding inside a document ready handler for elements that are in the HTML markup on the page. If new HTML is being injected into the page, select the elements and attach event handlers after the new HTML is placed into the page. Or, use delegated events to attach an event handler, as described next.

Delegated events have the advantage that they can process events from descendant elements that are added to the document at a later time. By picking an element that is guaranteed to be present at the time the delegated event handler is attached, you can use delegated events to avoid the need to frequently attach and remove event handlers. This element could be the container element of a view in a Model-View-Controller design, for example, or document if the event handler wants to monitor all bubbling events in the document. The document element is available in the head of the document before loading any other HTML, so it is safe to attach events there without waiting for the document to be ready.
...
...

Community
  • 1
  • 1
gdoron
  • 147,333
  • 58
  • 291
  • 367
  • 1
    was about to post this very thing. – Bradley Mountford Feb 23 '12 at 18:35
  • Hello, thanks for your answer. What is your reasoning in saying attaching delegate events to the document isn't recommended at all? What are the pitfalls? Performance? Isn't this the reason live() was considered poor practice? This is why I asked, as I've seen several "stack" developers say its better practice to pin something on the (document) vs the parent element or the element itself – Downpour046 Feb 23 '12 at 18:44
  • @Downpour046. Read the docs: `Since all .live() events are attached at the document element, events take the longest and slowest possible path before they are handled` So if you use `on` but attach the event to the document, you can keep using `live` – gdoron Feb 23 '12 at 18:46
  • 1
    @gdoron: That's not true, `live()` is deprecated. `on()` should always be used, unless you have an earlier version of jQuery. Even in that case, `delegate()` is recommended. – Purag Feb 23 '12 at 18:50
  • @Downpour046. jQuery has excellent documentation. Read about [on](http://api.jquery.com/on/) and about [live](http://api.jquery.com/live/) – gdoron Feb 23 '12 at 18:50
  • @Purmou. I didn't mean really use `live` i meant that using the new version without using the powers it gives you is not the way to go. – gdoron Feb 23 '12 at 18:51
3

I think you are confusing a few concepts. It is not recommended to bind to the document element, however there are times when you want to do so e.g when binding events to dynamically added elements.

All this may seem unclear, so here is the first example which uses the class selector directly and binds a click event, the element is inserted dynamically later after the event is bound. As you can see the event never gets fired because we selected an element that was not present in the DOM at the time the event was bound. This is equivalent to a .click

Now look at this second example. Here you see we are defining the root element as the document. Which means that the click event will bubble all the way up the DOM tree and then fire if the element that was clicked has a class dynamic. This is equivalent to .live

Now, if in example one, at the time of binding the event the element was present in the DOM, the code would work just fine, as you can see here.

That being said. Here's an except from the docs which clarifies the behavior above.

Event handlers are bound only to the currently selected elements; they must exist on the page at the time your code makes the call to .on()

So, in conclusion. Use the document element when you are sure that there's no parent element for the element you are selecting that's guaranteed to be in the DOM at the time th event is bound. If there is a parent element that is present then use that instead of the document element. This way the event will not have to bubble all the way up the document, it needs to travel only a short distance.

aziz punjani
  • 25,586
  • 9
  • 47
  • 56
2

There's nothing "recommended" about this. The first snippet sets up a "delegated" event, the latter is a "direct" one. The documentation for on() explains these in depth.

Delegated events are necessary when you need to listen to events for elements that don't exist yet - ones that will be created dynamically after, for example, an AJAX call. They can also sometimes be better performance-wise - you need less memory to attach a "real" event handler to the document object, than to 1000 buttons.

I'd say it's still preferrable to use direct event handlers when you can, or attach delegate events to an element as close to the real event sources as you can. Having all event handlers on the document object is probably terrible for performance - you have to match every event fired against all the selectors. It's also probably needed if you need to stop an event from bubbling - if all events are caught on the document, they've already bubbled as far as they'll go.

millimoose
  • 39,073
  • 9
  • 82
  • 134
2

Actually the best solution in a case such as this is not using the $(document) neither the specific element like $("selector").

The best approach is using the container of the element and bind the element selector in the on function. By doing this you avoid unnecessary event bubbling to the document.

So the code should look like:

$("this_is_the_container").on('event','my_element_selector',function(){
// do some stuff here
})
Bogdan Emil Mariesan
  • 5,529
  • 2
  • 33
  • 57
0
$(*selector*).on(*event*, function(){})

will apply only for elements which is already load in page at the moment of script run. If in future, will appear new elements, the event handler will be not work.

$(document).on(*event*, *selector*, function(){}

will execute event handler even the elements with same selector will appear on page after script run.

So, if you have some elements, which can appear after in random time, use 

$(document).on()

else use 

$(*selector*).on();
L Y E S - C H I O U K H
  • 4,765
  • 8
  • 40
  • 57
Dumitru Boaghi
  • 183
  • 2
  • 4