Vanilla JS: You Might Not Need a Framework

Event Binding & Handlers

Maximiliano Firtman

Maximiliano Firtman

Independent Consultant
Vanilla JS: You Might Not Need a Framework

Check out a free preview of the full Vanilla JS: You Might Not Need a Framework course

The "Event Binding & Handlers" Lesson is part of the full, Vanilla JS: You Might Not Need a Framework course featured in this preview video. Here's what you'd learn in this lesson:

Maximiliano discusses some possible DOM events that can be listened to, event naming patterns, and binding functions to events. Using onevent properties will only allow one function to be bound, while addEventListener allows binding multiple event handlers.


Transcript from the "Event Binding & Handlers" Lesson

>> So, of course that we need to do something more interesting, okay? Not that one. But before doing that I wanna go back to the slides and get a little deeper on Event Binding. Because we're going to have more event binding. Right now we have only the add event listener for DOM content loaded, but let's see more on the basics of event binding so we will understand better what we're going to do.

Each DOM element has a list of possible events that we can listen to, and there are a lot of events. For example we have load, click, double click yeah I'm not sure who is double clicking on [CHUCKLE] elements on the page but there is an event for that.

Change this has typically to do with form elements so when the contents of that element is changing. For example you have a drop down list select in HTML and the user is changing the selection well when that happens a change event will be fired. We have keyboard events key up key down key press mouse events, pointer and touch events for example on an iPad I can detect multiple fingers on the screen.

It's actually 11, don't ask me why 11 or where should they get the 11 finger [LAUGH] but it detects 11 fingers on the screen and for that you have the touch events, okay? On a phone it's typically five it depends on the hardware but it is typically five, so there are a lot of events we are not going to cover use all the events in this particular project.

But once you understand how to listen for one event, you just need to go and learn the documentation of the other events. The technique is the same technique you have changed the event name And the properties that you get from that event. We have a scroll, we have focus events and more APIs in the W3C that are even adding more events to the DOM.

Okay, for example, drag and drop. Apple TV support. Okay, so you can support streaming like casting, video to an Apple TV or to a Google Cast. And there are events that you can that those are not standard. So there are specific to those platforms that then you can bind events you know when an Apple TV appears in the same network.

So then you can show the icon to the Apple TV icon on your video player. So if you have ever seen on the website, sometimes it detects when you have a Chromecast in the same network or an Apple TV. Well, they're using DOM events APIs for doing that.

And some specific objects. They have a specific or special events that are not suitable for all the events, for example, DOMContentLoaded is one that is applied only to the window object. Or popstate is the one that we will use probably in an hour or so. And those are just for the window.

So if you try to listen for those events on other elements, nothing will happen, because those events are not being fired there, okay? The spec's naming pattern is to use lowercase with no word separator for event names. We have seen one exception. DOMContentLoaded. That was not lowercased, why?

Standards. Anyway, look at that event that you have at the bottom. I think that's the Guinness record on the largest event name. It's webkitcurrentplaybacktargetiswirelesschanged. And that's the event name no Camel case, no underscores, no hyphens that's the event that will tell you when you are transmitting video to an Apple TV.

When that Apple TV is off or something happened in the network and it's not available anymore. So it's telling you that it's changing wherever, okay? But you will see that most of the events are using this technique. Also, for some reason, also it's not completely, let's say, following the same naming guideline, in terms of, if you're using for example change or changed.

So if you use ed or e. Most of the DOM APIs are not adding, it's not clicked, it's click. It's not changed, is change. But when you are writing your own events, or for example, in this case, WebKit, that's Apple, for Apple TV, they're writing their own events, they're adding ed, or even DomContentLoaded, unload.

So, they're not following the same naming guidelines here. Okay, but let's say 99% of the event names are lowercased, no word separator, and no ed. So it's like, click, change. So to bind function to events in DOM objects there are two ways, onevent properties and addEventListener. So far we've seen only addEventListener but there is another one they say it's more classic in fact it's been with Dom since the first version.

AddEventListener is newer, anyway, newer I'm talking about the last 20 years, but the other one is 25 years. That's the difference. Onevent means that you have one property for every event. So instead of using load or click, we can use onLoadOnClick. For those of you coming from React.

You can feel that the on naming pattern is also there, with a difference or with a twist. There you are using camel case. Onclick, the C is a capital C, and react, I'm talking about react. Not on the DOM, onclick everything is lowercase ,okay? So what's the difference well for example here you have an example with an on. You say element.oneventname and function it's a property this case for example onclick onload, okay?

Lowercase, all lowercase. The problem with using this technique is that it's a property setter and getters If I assign twice different functions to the same property, the only one that is going to be fired is the last one. Okay? Because it's a property. You are setting, there is only place for one eventHandler.

An add event Listener, is using the observer design pattern, also known as poly-subscribe, where I can subscribe a lot of listeners or observers and all of them will be fire. So if I use this one, only one element will be fired. So that's why today it's typically, unless it's a very simple example, the very straightforward example.

You don't wanna use the on properties. We wanna use addEventListener. That receives the event name as a string argument. And then of course we can apply different events to the same element with the same event handler or different event handlers. And if you apply to the same element addEventListener with the same event name more than one, all the handlers will be executed.

So this is more interesting for us when we are doing applications, because then we can listen for example DOMContentLoaded twice. So window add event listener DOMContentLoaded and why this is better well, first, we can separate concerns. So we can say okay, let's first initialize this. Then I'm going to initialize the database, and then I'm going to initialize the connection to a web socket to the server.

And we can do this in separate functions, all of them will be fire and also they don't need to be defined in the same js file. Now we're going to start adding more JavaScript files in our project. And then I can listen for the same event on the same object more than once without thinking, did I already did that before?

Maybe I already bound that, so I cannot do that again. So it's more complicated. In this case, yeah, I wanna listen for a click of the button. Go ahead if other if other parts of your code is also listening for that that's fine, it will work anyway everyone will get its execution

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now