Understanding Events

We must try to understand what an event is when it comes to user interaction through the duration of a user session.

Events as defined by the W3C are very complex and can be tough to understand. However, the most common way of thinking about events in JavaScript is:

• Something happens to an element, to the main document, or to the browser window and that event triggers a reaction. For example, the window finishes loading and on that event we start an initialization method; or the user clicks a link and we use that event to trigger another function.

Most framework-generated code or even handcoded methods use this kind of event handling. We take the window, or a certain element and add handlers defining the event that should trigger a function. This leads to a rigid relationship between the markup and the functionality. As the interface of a web application might change (more links in a component, other buttons, more complex forms) this need to add more cruft begins to cripple our applications. It also means that maintenance must happen in two places — a change to our HTML means that our JavaScript needs to change, too.

The DOM Event Model however goes a bit further. It has a more granular definition of the workflow:

• Something happens; an event occurs.
• The investigation begins what element was activated and how. This happens by questioning each element from the window to the body to the first child node and so on until the element that was activated, the event target, is reached. This is called event capturing.
• When the element is reached, the process of reporting goes back up through the DOM right back up to the window. This is called event bubbling.
• You can intercept events on both legs of this journey at any time by adding event listeners to either the window or any of the objects that get queried. Event listeners define what event to look out for (click, keypress, load, mousedown…), the object to which the handler should be applied, and what method to call when it happens.
• You can stop events from going back up to the window by calling a cancelEvent() method and you can retrieve the object the event occurred on, the event target, with a helper method called getTarget().
• You can add as many listeners waiting for as many different events and each calling as many methods as you like.

Understanding and implementing this event model can free your application from the constraints of defined elements. For example, instead of applying an event listener for each link in a menu, you can assign a single listener to the menu item itself and retrieve the event target. That way you don’t need to change your script when the menu gets larger or when links get removed from it.

This is a very powerful and flexible approach often referred to as event delegation. Event delegation allows you to react to changes in the document while applying fewer event listeners. You can assign different handlers to different parts of your document (the menu, the main content, a sidebar, a language change menu) and define methods for each event (was it clicked? was a key pressed on it?). These methods then retrieve the element that was affected and react accordingly; for example, you can react differently for links versus buttons.

When using this idea (waiting for an event, investigating where it happens and acting accordingly) in web applications we mostly confine ourselves to what the browser reports us — the DOM events. This is not really necessary, and it’s a big limitation. Much that happens in an application — like a user switching between tabs in a TabView Control — could be thought of as an event and dealt with in the same manner.