5

I’m learning about how events work, mainly event capturing and bubbling in addEventListener. This article was great for the overall understanding.

Capturing and bubbling define the order in which events in parent elements occur. As far as I understand this is important because of event delegation. And addEventListener doesn’t actually delegate the events for you, it just searches for delegated events, is this correct?

Is there any other reason for searching the DOM hierarchy than for event delegation?

When I attach a DOM level 1 onclick event to a parent element and click on one of its children, I still get the child element as the event target. So I don't see the point in attaching an event listener to a child element and then bubbling up to search for delegated elements. There must be something I'm missing here..

Surely if you manually maintain your delegated events, there is no need to travel up through the DOM hierarchy searching for delegated events?

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
Dol
  • 944
  • 3
  • 10
  • 25
  • 1
    Are you talking about using the `onclick="..."` attribute to attach a handler instead of `element.addEventListener()`? I'm not 100% clear about what you're asking. – Greg Burghardt May 04 '15 at 17:17
  • Are you asking about [addEventListener vs onclick](http://stackoverflow.com/questions/6348494/addeventlistener-vs-onclick) in respect to delegating events? – Greg Burghardt May 04 '15 at 17:20
  • As part of a bigger question yes. Thanks I didn't find that other SO question. – Dol May 04 '15 at 17:21
  • could you change the title of your question to reflect that? I think it's an interesting question, but the title doesn't quite match. – Greg Burghardt May 04 '15 at 17:22
  • Sure. I'll change it now. Could you add that link to your answer? Ill mark it correct. – Dol May 04 '15 at 17:24
  • 1
    There is absolutely zero difference between `addEventListener('click', …, false)` and `onclick = …` in regards to event delegation. Both just attach a handler to one element. The event does always bubble when triggered. – Bergi May 04 '15 at 17:30

1 Answers1

5

And addEventListener doesn’t actually delegate the events for you, it just searches for delegated events, is this correct?

No. It does absolutely nothing with event delegation, but can be used as part of event delegation. The addEventListener method adds an event listener to a DOM node, which responds when the event bubbles up to, or propagates down to, that element.

Event delegation is a combination of adding an event handler to an HTML tag container via addEventListener that responds to the bubbling events of the elements inside it.

When I attach a DOM level 1 onclick event to a parent element and click on one of its children, I still get the child element as the event target. So I don't see the point in attaching an event listener to a child element and then bubbling up to search for delegated elements. There must be something I'm missing here

Event delegation is beneficial for three main reasons:

  1. You don't need to remember to add event listeners to elements when you add them dynamically to the document
  2. You don't need to remember to remove event listeners from elements when they are removed from the document. Not remembering to do this causes memory leaks in browsers
  3. You end up with less JavaScript code for event handling. Fewer lines of code means fewer changes for introducing bugs and less code to maintain.

Dol said:

But surely I should get the benefits of event delegation by attaching a DOM level 1 onclick to an elements parent (like I described), rather than the element, without needing to use addEventListener or having to search through an elements parent nodes for delegated events?

Whether you attach the handler to the parent of the target of the event is irrelevant. If you want a JavaScript function to execute in response to a user event, you need to use addEventListener. That's just how it's done.

addEventListener vs onclick when delegating events

The real question here appears to be:

"What is the benefit of using addEventListener over onclick="someFunction() or element.onclick = function() {...} in regards to event delegation.

The following StackOverflow question gives general advice on addEventListener vs onclick.

In regards to event delegation, it really boils down to this. If some other JavaScript code needs to respond to a click event, using addEventListener ensures you both can respond to it. If you both try using onclick, then one stomps on the other. You both can't respond if you want an onclick on the same element. Furthermore, you want to keep your behavior as separate as you can from the HTML in case you need to change it later. It would suck to have 50 HTML files to update instead of one JavaScript file.

If you use the document.documentElement object to attach event handlers to, you don't need to wait for the "domready" event or a page load event to attach your delegated events. The document.documentElement, which represents the <html> element, is available for JavaScript the moment it begins executing on the page.

Community
  • 1
  • 1
Greg Burghardt
  • 17,900
  • 9
  • 49
  • 92
  • Thanks. But surely I should get the benefits of event delegation by attaching a `DOM level 1 onclick` to an elements parent (like I described), rather than the element, without needing to use addEventListener or having to search through an elements parent nodes for delegated events? – Dol May 04 '15 at 17:11
  • 1
    Just one correction, the question is not referring to the `DOM level 0 onClick` attribute event, its referring to the `DOM level 1 onclick` event, as described here: http://blog.bitovi.com/a-crash-course-in-how-dom-events-work/ – Dol May 04 '15 at 17:32