简体   繁体   中英

Is it crazy to delegate tons of element event listeners to document.body?

After reading about optimally-performing JavaScript, I learned it's best to minimize interaction with the DOM, and rely more on the logic within JavaScript itself.

Part of this is using a single event listener for a list of elements and reading the click target, rather than an event listener for each and every one

ul#menu
  li#one One
  li#two Two
  li#three Three

$ul = document.getElementById('#menu')
$ul.addEventListener('click', function(e) {
  if (e.target.id == ...) { ... } // You get the idea
})

I have a website that has several navbars, several dropdown buttons and such. So why not create a single event listener on the body and just look at the event target?

document.body.addEventListener('click', function(e) {
  if (e.target.id == ...) { ... };
})

I can't tell what's wrong with this solution from a technical perspective. Something just seems too heavy to me, it has a code smell to it.

Would this be problematic on mobile? Does the nature of <body> being high in the DOM end up doing more damage to performance than good?

I'm not using jQuery , please suggest pure JS solutions.

After reading about optimally-performing JavaScript, I learned it's best to minimize interaction with the DOM, and rely more on the logic within JavaScript itself.

I'm not sure what this means. Whatever it does, did you also read the part about when to worry about optimization (later, or never, or when you really have to)?

Part of this is using a single event listener for a list of elements and reading the click target, rather than an event listener for each and every one

This is a model which is best applied in cases such as where you have a hundred <li> elements to listen to events on, so rather than attaching event handlers to each and every one, you attach one event handler to the <ul> . Personally, I'm not convinced that there's such a major benefit from doing this, but in any case that is the logic.

There are two reasons why this could be beneficial:

  1. There is only one event handler occupying memory, instead of 100. In this day and age, that is not too convincing.

  2. When new elements are added, there is no need to explicitly add event handlers to them, since an event handler is already in place on their ancestor. This could indeed make program logic simpler.

However, extending that to putting one master event handler on the body is going way too far . As one commenter mentioned, the logic in that event handler is going to end up being a massive pile of spaghetti.

A good basic rule is to put event handlers on the element involved, or on a nearby ancestor parent element to handle events in the same or similar ways on multiple children/descendants.

So the answer to your question of "is it crazy" is, yes .

Why would you ever want to optimize something like that? Compared with the memory footprint of a single background image or the truckload of JQuery thingies your application will never use, that's peanuts. As for CPU usage, that would be measured in microseconds per hour. I very doubt your main performance issue will come from there.

Factorizing code is just the same story anywhere, be it in a JavaScript event handler , an OpenGL shader or a c++ template. You do it when it proves more useful or convenient than writing slight variations of the same code all over again.

You might also want to do it because your boss told you so or some influential jerks named it "good practice", though.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM