DOM handleEvent: a cross-platform standard since year 2000

A solution to many problems

This is a mandatory TL;DR for all developers believing they fully understood what is handleEvent about and what does it solve:

  • it’s the best solution in terms of RAM. Applications will not “explode” or crash on emerging markets devices. You won’t ever retain extra unnecessary bytes for the sake of a component context.
  • one single entry point to handle every ordinary or custom DOM event. You’ll never need to bind another property, you’ll never need to change your class definition with another arrow. Your components will always be ready to handle a new listener without any maintenance at all.
  • it’s more secure than reassigned properties. Whenever you comp.method = comp.method.bind(comp) or you comp.method = e => comp.stuff() you are creating a public enumerable property at runtime instead of keeping behaviors at class, object, or component definition time. With handleEvent you can create a single private delegate to handle internally everything you want, giving you the ability to expose and use the same component both internally and externally.
  • it is always possible to remove a listener. You’ll always be able to drop that listener that’s not supposed to happen again. No listeners defined in closures issues, no unreachable bound methods as in el.addEventListener(type, this.method.bind(this)) which makes you lose control of your own application.
  • listeners have a meaningful context instead of a redundant one. Every listener function will be invoked with a context that is exactly the event.currentTarget information any event would already carry.
  • strawberry on top: if you add by accident 2 times the same object as listener, it won’t be fired/dispatched/triggered twice ’cause it was already known, so the platform will avoid redundant dispatches 🎉

How does it work?

The handleEvent ABC is that any object that implements such method will be invoked as obj.handleEvent(event) once the event happens.

About Memory Consumption

You don’t need a degree in math to realize if you attach one or more new properties to every new instance you create, the used memory will be inevitably more. Of course, bind usage might be lighter than arrow function, yet if you don’t need to use either at all, why would you?

One instance to rule them all

An object that implements handleEvent can be used both internally and externally to intercept and react to any sort of listener.

But Security First

Some developer mentioned to me components created in this way give other parts of the code the ability to arbitrarily remove any listener they use.

Listeners can always be removed

I’m restating and repeating myself here, and I’ve written this in this October 2015 blog post too, every time you add a listener and you don’t reference it it’s like creating a setInterval without having a way to ever stop it.

If you need a context, do it right

I think it’s clear by now why handleEvent is the right choice when you use classes or components.

If you accidentally add an object twice, you’re safe

If nothing else convinced you by now, think about the following:

What about Frameworks?

For what it matters, every code of mine since about year 2000 supports handleEvent behavior because I know, and use, this pattern since long time so hyperHTML, as example, is safe to use without any issue.

  • is your framework supporting handleEvent? Awesome! Start seeing where this pattern can be useful.
  • is it not? Please file a bug or send a PR to such framework asking why they don’t and, maybe, point at this blog post if they need to know more.

As Summary

It’s our duty to also care about cheaper devices with less RAM constrains: the Web should be available for their owners too.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Andrea Giammarchi

Andrea Giammarchi

Web, Mobile, IoT, and all JS things since 00's. Formerly JS engineer at @nokia, @facebook, @twitter.