Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Is there a reason to removeEventListener DOMContentLoaded after the event has been handled?

Like many others I use:

document.addEventListener('DOMContentLoaded',domLoadedFunc,!1);

In combination with window.onload to handle events that should fire as soon as the DOM has been loaded and parsed.

I was wondering if there is a reason to explicitly remove the DOMContentLoaded listener once it has fired.

Something along the lines of (inside our domLoadedFunc):

if(document.removeEventListener){
    document.removeEventListener('DOMContentLoaded',domLoadedFunc,!1);
}

Is there a reason to remove the DOMContentLoaded listener once it has fired?

like image 973
anonymous-one Avatar asked Apr 15 '14 19:04

anonymous-one


People also ask

When should I use DOMContentLoaded?

The DOMContentLoaded event is a useful event that can make a big impact on the performance of your pages, hence this example. It fires when the HTML and scripts that make up the page have loaded, but not necessarily the images or CSS.

Why should you remove event listeners once they are no longer used?

The event listeners need to be removed due to following reason. Avoid memory leaks, if the browser is not handled it properly. Modern browsers will garbage collect event handlers of removed DOM elements but it is not true in cases of legacy browses like IE which will create memory leaks.

What triggers DOMContentLoaded?

The DOMContentLoaded event fires when the HTML document has been completely parsed, and all deferred scripts ( <script defer src="…"> and <script type="module"> ) have downloaded and executed. It doesn't wait for other things like images, subframes, and async scripts to finish loading.

When should I remove Eventlistener?

TLDR; Always remove event listeners when you don't plan on using them any longer.


1 Answers

Once the event has fired, it will not fire again. So, your code will not have any different outcome if you remove it or not once it has fired the first time.

Technically, if you had a lot of event handlers all attached to the document object, it might be ever so slightly faster to remove event handlers that are no longer needed, but that is balanced with the extra code you write and execute just to remove it.

Personally, I code with thoughts in this sequence of priorities: correctness, reliability, readability, maintainability, simplicity and then performance and only do anything purely for performance sake when it's actually needed. So, following that hierarchy, I wouldn't remove the event handler because doing so is not needed for any of the first four priorities, doesn't help the simplicity of the code and isn't a performance issue that matters.


The one reason I have seen for removing an event handler like this is if you have multiple different events you are monitoring and once the first one is triggered, you want to make sure that you don't respond to any of the other events you're also monitoring. If you then remove the other handlers, then you don't have to keep a separate flag to keep track of the fact that you've already done your work (for example, if you were listening for both DOMContentLoaded and window.onload and just wanted to respond to whichever one happened first.


FYI, if you're interested in a plain javascript version of jQuery's $(document).ready() which works in all browsers (uses DOMContentLoaded when available, falls back to other means when not) which it sounds like you might be working on, there's a nice simple to use implementation of a function called docReady() here: pure JavaScript equivalent to jQuery's $.ready() how to call a function when the page/dom is ready for it that you can either use or copy/learn concepts from.

like image 80
jfriend00 Avatar answered Oct 11 '22 15:10

jfriend00