My adventure in JQuery

I hate click handlers…..there I said it. It has been my experience that every program has included some kind of event handling; today was no exception.

In short the requirement was to add a click handler to a constantly updating list of “chats.” Those newbies out there, “myself included,” might say, “Oh that’s easy, just add in a line of code that ‘listens’ for clicks, and then…..do a thing.” That would be correct, if it was not wrong.

Among the many other nuances that go into constructing a proper event handler, element or attribute to select…how to get data, name, or what have you, to carry out the next step. Probably the most important element is when to apply the handler. That was the case for todays frustration.

Lets talk about what an event handler does. It sits in the background of the DOM just ‘listening’ for a certain event to happen. The list of things that can be events is too numerous to list, when considering multiple languages, but more common examples would be ‘click’, ‘hover’, and ‘keyup’. The problem with this is that the time in which an event listener is applied and when it is called, can be any length of time, and with that in mind, the element may not be there yet, or anymore. This can lead to intermittent problems, with an anomalous origin. It can be made even worse when event handlers occur at one point and not another.

In today’s coding sprint we were tasked with adding a click listener to a list of events that would be constantly appearing and disappearing. As you the reader can probably tell from the discussion above, what happened lead to hours of reformatting to determine the cause.

A normal click listener may look similar to below:

$(‘something’).on(‘click’, function(event) {
Do a thing
});

The above code will listen for a click, on the something to perform some action. However!, one caveat to this is that an even listener is only as good as when it was applied, so the above code may run, but only if that something was already there when the page was loaded.

So what can we do to get around this? Our solution was as follows

$(‘Something permanent’).on(‘click’, ‘thing we want’, function(event) {
  Do our thing;
});

Two things needed to be done, which separate the second code from the first. Note that the thing we want the event listener to be applied on may not be present at this time, but we can know what form it will be, and we know what elements will be present at load time. Additionally, it is important to know that a listener can be applied to an element, and by proxy, any of it’s contents. With that in mind, the click handler can be applied to the page itself, or to be more precise which element of the page to which the listener should listen. The above pseudo code calls for the listener to listen to something permanent, and on the ‘click’, it will look for the thing we want. Which can be nearly anything, a DOM element, class, id, etc. and this click event will be applied to that. This is helpful, since the thing we want may only be present after something else has happened, in which case, it the previous event handler could not be applied, while the latter would wait for it to arrive.

So in closing I hope my above frustrations may help any readers to find an otherwise elusive solution. The above logic can be applied in other manners such as finding child nodes, but that will be a discussion for another day. Again I hope this was helpful, and Lederhosen!