Transcript from the "Advanced Event Handling" Lesson
>> So typically, we are going to use addEventListener. And also, addEventListener supports more advanced event handling. For example, we can pass a third argument with some options. For example, one option is once, that by default this is false. So typically, we set it as true. That means that the event will be fired once.
[00:00:22] After it was fired once, the eventHandler will be removed automatically. So if you add these to a click eventHandler on your button, you click once you execute the handler. You click again, nothing will happen, because the event was removed. Yeah, it's not suitable for a button, but it might be suitable for other situations where you're expecting that to happen once.
[00:00:47] So then you don't need to think about removing the EventListener about leaking options, blah, blah, blah. Passive, I will try to explain it really quickly. If you don't get it, it's fine, okay? But let me explain that with a scroll, since the simplest example is with a scroll.
[00:01:11] Remember that I mentioned that we are sharing the thread between my code and the browser, but it has to do with that. So what happens, for example, if you are scrolling with your finger, you are scrolling your phone with your finger, and there is a scroll event, so you can know when the user is scrolling the page.
[00:01:56] If you are changing the DOM, then it needs to repaint, relay out before actually moving the layer, something like that. When you say passive, true, you are kind of saying, hey, browser, you can safely do whatever you wanna do on the screen that I'm not going to change the DOM.
[00:02:15] I'm simplifying this a lot, but just to give you an idea of what this is, okay? So it's like saying, hey, you can execute my EventListener passively, so don't wait for it to finish before doing your stuff. It something like that, it's more complex than that, but just to give you an idea.
[00:02:35] Anyway, there is an option the third argument where you can execute some code. And also, we have removeEventListener. Why do you wanna remove EventListeners? Well, to avoid having connections to things that you're not going to use anymore. This is only useful when you are doing a single-page application, and you are adding and removing elements on the page.
[00:03:24] We don't clean up the Web app for when the user gets out. That's not how a Web app works, okay? So we use these only when we are injecting and removing elements. And we don't wanna get a lot of functions in memory that we don't use anymore. Does it make sense?
[00:03:49] That's kind of the idea. And this is actually pretty cool. And it's an underused feature that we're going to use it later. We can dispatch our own events. And not just for our own components that we haven't created yet. We can dispatch events in the document, in the Window object.
[00:04:11] So you create a new event with your own name, and you're not forced to follow the lowercase guideline. So it's just a string, and dispatch that event over an element. And that element can be a button, or it can be the document. So you can broadcast events through the DOM API for anyone that wants to listen for that event.
[00:04:37] Now, think about React Angular. This is kind of a context where you can dispatch events over the context, and anyone in the DOM can subscribe with a provider, and that's kind of that idea. So we can dispatch events from anywhere in the page, and anyone can listen for those events.
[00:05:33] It's just one technique that we have available when you're doing Vanilla JS, okay? Cool, do you have any question? Yeah.
>> I have two actually. So did you say that when DOM nodes are removed from the DOM specifically, that the EventListeners aren't removed? Do you have to remove them manually?
>> Let's review that part, because there are several possibilities here. So if you remove an element from the DOM, do we need to remove the EventListeners? It depends on what you wanna do. Because removing an element from the DOM doesn't mean that you are not going to use that element anymore.
[00:07:10] Actually, it depends. It's not even a clear answer, because it depends if you also have that EventListener hooked somewhere else or not. So it's not so complicated, but it is complicated actually. It's not so simple. But something that you can do is to manage that yourself and say, okay, I'm going to remove the EventListener for that element.
[00:07:34] But more important is that when you don't need that EventListener anymore, let's say you have a button, you have a help button, okay, that is on your page all the time, but then you log out. When you log out, you need to remove an EventListener from it. Because now you are logged out, you don't wanna open a chat that connects to your account, because now you are logged out.
[00:08:01] The button is still there, so you are not removing the button from the DOM. It's not about the element itself, it's about the use case. Now, there are one or more event listens over that element that is still on the screen that you don't need anymore. So you remove the EventListener.
[00:08:19] That use case is more common, make sense? But yeah, the other problem is what happens with typically custom elements that we put on the screen, and then we'll remove from the screen and we won't use anymore later, okay? Cool, any other question?
>> I have one more actually.
>> Yeah, sure.
>> When you have multiple EventListeners for one event like load for example.
>> Did they fly synchronously one after the other or?
>> Is there a limit to how many EventListeners can be honored?
>> That's a good question. If they're limited, how many EventListeners can you hook? Actually, it depends on the implementation of every browser. I think there was someone doing a test, and some browsers were crashing after 5000 or something that. But I mean, in the real world, no. But there is always a limit, because it has to do with memory and browsers implementations.
[00:10:13] But I'm not pretty sure right now, but I don't think there is a limit in the spec. So but yeah, each browser might implement the things differently. So they might have their own limits or something like that, creating a DOM exception when that happens. But it's not happening in the real world, okay?
[00:10:32] Even really complex BR, games, somethings won't get into that level of problems.