How to effectively attach eventListeners to DOM elements

Anonymous functions are great way to quickly get the job done, but can be a huge problem when used carelessly. It is especially when attaching eventListeners to DOM elements. Take the code below for example. Here we are attaching an eventListner to the element for the “click” event. Now, later lets say for some reason or requirement we need to remove this “click” listener.

var element = document.getElementById("my-id");
element.addEventListener("click", function() {
// handle event

After this point we don’t have any reference to this handler since we forgot to keep a reference to it hence we cannot call the removeEventListener on the element, and the function stays in the browse memory.

Now assume the same scenario with multiple elements. An appropriate example of it might be when a NxN grid of elements is created. Lets assume that the cells in the grid is being created dynamically and appended to the DOM. If these cells need to have some event handler we might end-up doing the following:

var newCell = getNewCell(); // function to create a new cell

newCell.addEventListenet("click", function() {
// handle code

This way we ended up creating NxN anonymous functions to which we don’t have references to, in case event listeners need to be removed. Even after the element does not exist in the DOM, it is the browser to decide when to remove these abandoned listeners from its memory. But as a programmer its our job to clean up the mess we created.

How to fix this:

A better approach to add eventListeners to DOM elements would be to have some kind of reference to them as below:

function myListener(event, target) {
// handle the event

var newCell = getNewCell();

newCell.addEventListener("click", myListener);

Now whenever needed, this listener can to removed from the element:

newCell.removeEventListener("click", myListener);

Sometimes, there is a requirement of firing en event listener only once (for example an init button to be clicked for initializing the application). In that case, the addEventListener method can accept an optional object parameter with a Boolean property “once” to tell the browser that this listener needs to be fired only once and after that the listener needs to be removed. So in such cases adding anonymous function as eventListeners can be considered fine (but not with multiple elements as we are still creating several anonymous functions which will sit there untill the event occurs for the first time).

myElement.removeListener("click", function() {}, {capture: false, once: true, passive: true});

So it is quite essential to take precautions when attaching anonymous functions as eventListeners especially with multiple elements.


Handling The Junk Code

While writing applications most of us have the bad habit to abandon few pieces of code here and there in the process of optimization and performance tuning. Few lines of codes get completely replace by better ones and few need little tweaks here and there though, there is a good amount of code which is replaced by better ones not because they are useless but not suitable for that particular situation. Since we know this truth, we find it very hard to delete that code, instead we keep a copy of it somewhere in the same program in an area where few other codes are dumped. This place looks like a junk yard which has high potential but definitely not very organized one.

If somebody likes the code very much and does not want to throw it into the junk corner, they hide it under the comment section and put add a TODO or UTILS line above it, surely a very bad practice for production.


So, What to do with this Lovely Junk?

So what to do with this box full of good but unused code and where do we put it so it can be utilized in the later course of time? Definitely this box has to be kept far far away from the production code. Why? Since these codes have been replaced by others there is a big chance that the new code(generally a method, function or a Class) happens to have the same name and often same signature too. Its pretty clear that having multiple codes with same signature can have catastrophic effect in the later run when a new developer join the team.

A good solution would be to take the code away and put it in a repository where it feels safe and can be revisited and shared with other members. If the project is Open Source in nature, putting the junk code in an online code repository and in the organization’s own private code repository. One thing that has to be taken care of is that, it has to be put in a repository separate from the actual project. This will surely save time as developer does not have to re write the code again from scratch.

Happy Coding 🙂