Event Bubbling, Capturing — Everything that you should know
What can we expect from this blog
With so many frameworks in the market and its ease of adding event handlers, developers tend to add unnecessary handlers where things can be done with less code. This blog will help you to understand some core concepts of JavaScript like Event Bubbling and Event Capturing. You will be able to take advantage of it and implement Event Delegation and Measure its performance.
What is an Event?
An “Event” in a web application can be defined as an action taken by user interaction, a server notification or registered data source changes. These events have handlers associated with them to execute some action.
Example: click on a button
Have you ever wondered how a Browser understands where a user has clicked on such a massive DOM tree/forest? The Browser needs to be intelligent to find that out efficiently.
Browsers use a concept called Event Capturing. Let’s talk about it in more detail.
What is Event Capturing?
Whenever a user clicks on the button, the Browser starts to find out which DOM node has been clicked. But it neither knows the answer nor is there anyone to give it. Next step for the Browser is to start asking everyone in the tree. It starts from the root tag <html> and asks, “Did the user click you?” The <html> tag says “not me exactly, but one of my children did”. Then it starts to ask its children. Asking the <body> tag and so on.
Finally, it reaches the <button> tag and it replies “yes, the user has clicked me”. The Browser then stops its search operation as it found the target/origin of the Event.
This process of finding out the target element, which is a source of an event, is called Event Capturing.
Wow, what about handlers? We can have multiple handlers for one action, right? Now to get the answer of this, you need to first understand Event Bubbling.
What is Event Bubbling?
After we have captured the target of the event, Event Bubbling comes into the picture.
It is a process where an event gets propagated to its parent to see if there are any further handlers registered for it.
Say, you have a <button> inside <div>. You can add handlers to both of them. Now, through this mechanism, both the handlers get executed. First, the target element gets priority and the event bubbles to a higher level.
Example:
Output:
Can you stop this propagation?
Yes, we can. There are certain methods on an event object which can stop this propagation when you find everything is handled at certain points. You use them when you are sure an event has handled all the cases and nothing is left to execute. You can stop and let the JavaScript do other tasks.
Example:
Output:
If you look at the output, the second handler is not executed because we have prevented its propagation.
There is an interesting concept Event Delegation, which uses the power of event bubbling and implements the best code.
Event Delegation:
Handling multiple events on similar (not strictly) children in one handler at parent level can be called as Event Delegation.
Consider the scenario below We have 10 <li> elements, when clicking them we have to set background to red. I have attached a click event to each <li> tag.
Example,
output:
You will find the background of <li> element changes as you click on it. But this does not take advantage of Event Delegation because all elements have a common parent called <ui>, which can handle every click.
Implementation with Event Delegation:
output:
As you can see, we are using a single handler and managing clicks on each list item at one place.
If you handle multiple actions at one place you need to identify which one you are executing currently. For that, I have attached “id” to each element and when execution comes to the handler it will always have event.target as the element which is clicked. From this key, we will be able to identify, who is clicked.
What is “target” and “currentTarget”?
These are the two terms developers uses to identify who is handling an event and who is originating an event. For our case, <ui> is the handler and <li> is raising the event. When you say, event.target it will be your <li> DOM. event.currentTarget will be your <ui> DOM.
Performance:
I promised a lot for Event Delegation. How can we prove that? I tried measuring performance from the performance tab in the Chrome Developer Tool. I used delegation at one place and multiple handlers on another side. I had the following observations:
Observation one: I used 1000 <li> tags and performance was:
Without delegation
with delegation
Observation two: I used 100000 <li> tags and performance was:
Without delegation
with delegation
Conclusion
I was not impressed with the observations I got. I found around 100–200ms gain in performance. I was thinking, do I really need to worry about it? But when I looked at my DOM, I saw the subset for making judgments too early will be wrong. Consider an E-commerce DOM tree, how huge it would be? This makes us a little bit more confident about, yes Event Delegation is the way for performance as long as event handling is considered.
