Javascript Events and Decoupling

How using native and custom events in your programs helps to simplify and modularize.

Events are one of the single most important tools in your development toolkit as a JS developer. Whenever you want to have your script react to any user interaction on the page — a scroll, a mouse click, a tap on the back button, etc., you will generally write an ‘event listener’ into your script. In vanilla JS, that will be something like:

In the above code snippet, you are adding an event listener on the highest level node in the DOM tree: the document node. All of the elements in the DOM are descendants of this node. If you don’t know too much about the concept of nodes, I recommend this introductory article from MDN.

Decoupling with Events

Events are fantastic because they implement a pub-sub software pattern. Pub sub stands for publish subscribe’, and it is one of the tried and true methods of decoupling two software systems from on another.

In the case of Javascript Events, the two systems that are being decoupled are the DOM and the Javascript program that you have written as the developer.

As long as your script has access to the browsers DOM methods (which is always) you will be able to add a listener to any of the nodes in the DOM and watch that event. ALL of your scripts will have the same experience. When the scroll even fires in the browser, events from many disparate scripts can fire off. This is really valuable because the event itself is completely separate from the listener methods that might be reacting to it.

Custom Events

Javascript also allows you to create custom events, that bubble up in the same way and provide the same great advantages of decoupling the event from the listeners.

You create a custom event like this:

You then need to dispatch the event which will set the event bubbling up in the DOM:

You will then be able to listen to the event anywhere in the DOM:

I find myself using custom events for all sorts of things, dropdown events, clicks that trigger modal openings, and global events like language changes.

You’ll of course want to send information along with the event. That can be handled like so:

This will then allow you to access the additional data in the event listener:

By hooking into this DOM API, you will be able to reduce dependencies between your scripts and more fully modularize your scripts. Instead of having a function inside of your language toggle that has 15 callback registered to it, you can create a single event called “languageToggle” that has 15 different listeners, across 15 different scripts. This helps to keep code clean and modular.

Happy coding,

~ Alex Zito-Wolf

Product Manager + Software Developer. Interested in Travel, Culture, and the Internet.

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