Events and Listeners

[00:00:00]
>> Let's talk about events and listeners for that matter. So think about designing a website. Not everything happens immediately, right? A user is going to land on your page. They're gonna start reading things. And they're gonna make a decision to do something. As the developer, you have to wait for the user to look at your website and then make a decision and do something.

[00:00:25]
So you have to be reactive, right? You have to wait. Everything that I've shown you so far is what we say synchronous, right? A user loads the page and it immediately runs all this code, right? Remember that one that we did, where we repeated that string immediately, right?

[00:00:41]
Not all coding is like that, much of it isn't, right? Particularly JavaScript, it's a lot about waiting for something to happen. Enter events, that's what events are for. So imagine, I have this Click me button here. I'm waiting for the user to figure out that I want them to click this button.

[00:00:59]
This page has been loaded for how long, right? It's been loaded for a couple minutes. So if I click this, I get a nice little alert that says, Hey there! How did I do that? How did I wait for something to happen? Well, let's take a look. First thing, I'm gonna give you a live little note here.

[00:01:17]
You can attach multiple of event listeners to a single DOM node, right? So if I modify this, it's not going to replace this event listener, it's going to add to it. So if I put a question mark here, this is now run again, right? Because it runs every time that I type.

[00:01:35]
It's gonna do this twice, right? So I just wanted people to be aware, if they do this, right? I've now added a lot of events listeners to this, right? Just be aware of that, weirds some people out. And just to clear it, just refresh the page. Okay, so first thing, I grabbed my button.

[00:01:59]
So I have the Event button. So I grabbed it here with querySelector. Then I say, button.addEventListener, and I am listening for what? Clicks, right? A mouse click. Technically, I think a touch would count for this most of the time as well. But you can actually listen to touch start and touch end, right, specifically for mobile phones.

[00:02:25]
And then you say, whenever a click happens, do this, Right? So I'm just using the alert, right? Alert is the most annoying thing in the possible world. I don't think anyone's happy when they see one of these, right? So don't do that, people hate it. Let me tell you as someone that's been a developer for a long time.

[00:02:46]
People hate when you do this to them, but it's also a really easy way to demonstrate to you reactivity, right? But you could totally say, console.log('lol') or something like that, right? And you can see all the various different permutations of that going on here. But yeah, so that is the most basic event listener.

[00:03:17]
There's so many events you can listen for. There's keyup, there's keydown. If someone presses something on the keyboard, there's keypress. I think we've talked about touch start, there's touch end. There is paste, there's cut, there is right click. There's so many different kinds of events, Okay? This function here, we call it a callback, cuz basically you're saying, hey, whenever this happens, call me back, right?

[00:03:50]
This function only gets run whenever this event happens. Yes, people often get confused, this looks really weird, Brian. What is this? Why is there so much stuff going on here? Just think about it. This needs to be closed, right? You can see they're highlighted in green at the moment, right?

[00:04:13]
So this, the first one refers to this one. And then this one refers to this one. So it's just closing everything that was opened, okay? Yeah, so alert comes from the DOM. Technically, it's window.alert, right? Okay, so let's do another one here. I had this input here. And right now, underneath it, it says, nothing has happened.

[00:04:50]
Here, I'm listening to input-to-copy, which is this input, right? And then I have this paragraph here, which is this one here, p-to-copy-to. And add an event listener for keyup. So whenever someone hits the key and then comes back up. You can also do keydown, that's another button press, right?

[00:05:13]
Then I'm gonna set the paragraph's innerText to input.value. So if I type the letter F here, what do you expect to happen? I expect nothing has happened yet to change to F, Right? There you go. This allows you to kinda have these interactive elements to your website. So why are we using keyup?

[00:06:02]
Well, if we were doing keydown, we'd actually always be one key behind. Well, hold on. How is the easiest way to do this? Cuz it already has this event listener. Anyway, suffice to say, I don't think I can show you this quite easily. But if you did keydown, then you'd always be one down, because it would press it and it wouldn't register the key button key yet, so you have to keyup.

[00:06:30]
Yeah, it registers before the key actually registers. And we're referencing input.value here, right? So input is this input. Whatever the user has put into input, that is going to be the input.value. That's where that comes from. Okay, and then we're just passing that directly into paragraph.innerText, which is the text of whatever's inside of it.

[00:06:59]
We could also have this be like innerHTML. I think this should work. If I say m, Right, then it'll actually put HTML directly here. Which is kinda cool, right? You can actually put this as innerHTML, right, like this. And then I could say, em>lol or something like that.

[00:07:28]
And actually put HTML directly out into the DOM. This is a huge security vulnerability. Reddit could never do this, right? Because that means other people could load their comments and say, exfiltrate all of their Apple Pay information or something like that, right? So typically, you don't wanna put untrusted-ish email directly into a document, it's just a bad idea, in general.

[00:07:52]
But it's still possible if you want to. Bad ideas are still possible. God bless the Internet. This one's kind of a fun one. Let's try this. So I have my color-box. Its background is a lovely shade of lime green, width and height of 100 pixels. Here's the color-box.

[00:08:13]
Here's the input. I am then going to listen for change events. So what happens with a change event? As soon as a user does something and then unfocusses from the input, it'll register a change event. So for example, if I type pink here, nothing has happened. But if I click somewhere else, what do you expect to happen?

[00:08:36]
It's gonna become pink, right? So that's a change event. As soon as something has changed and then unfocusses. So even if I do this, Nothing changed, right? So it still registers that something needs to change between these two different things. But now, you can say, I don't know, I want this to be black, White, mediumorchid, right?

[00:09:05]
Anything that's a valid color would work here. Kind of just stringing all these various different tools we know together to create these kind of cool interactive experiences. Let's talk a little bit about event delegation slash event bubbling. I don't really wanna get you too much into this. Again, this is another favorite question to ask to junior Frontend developers.

[00:09:22]
So it's worth delving into if you're gonna do interviews. Right now, I'm listening to events right at the source. Every time that this input has an event, I'm listening to it right up at the input level. Technically though, I could listen to it at the level above it, or the level above that, or the level above that.

[00:09:41]
So the events bubble up to their parents, until eventually goes to the HTML level and it fizzles out from there. But you can take advantage of that. So I have five buttons here and a button-container of 1, 2, 3, 4, and 5. I could go and add an event listener for every individual button, that's a little bit burdensome, right?

[00:10:07]
Because you have to write an event listener for every single button. Wouldn't it be nice to just have one event listener that listens to all five? You can do that. So I can listen for events on button-container instead of on any individual button. Rather than listen to events on any one individual button, you can listen to it at the parent level, right, cuz the events will bubble up.

[00:10:32]
So I have these five different buttons, but you can see here, I query the selector button-container, and then I add an event listener that listens for clicks at the button-container level, right? And then an alert that you clicked on the event.target will let you know what was clicked, right?

[00:10:54]
So in this particular case, it'll let me know that if I click on button 3, like this, event.target refers to the whole button here, right? Or if I click on button dot this one, you clicked on button 4, cuz I'm reading the innerText out of the button. Now, what's the danger here?

[00:11:19]
What happens if I click between the buttons, Right? It's reading the innerText, which is 1, 2, 3, 4, 5 of all of them. So you do have to be a little careful. I could put some logic in here to say, is event.target a button, right? If it is, do this, if not, ignore it.

[00:11:42]
That's how you would do that. But still pretty cool, I can just listen at the button level, Or at the container level, and not have to worry about assigning one for each individual button. This is called event delegation or event bubbling, whatever you wanna call it. And yeah, so that's kind of the gist of DOM interactions, right?

[00:12:12]
You wait for events, an event happens, you do something about it. It's largely gonna be clicks, and keyups, and keydowns, and touch end and touch start, if you're doing touch stuff. There's a thing called pointer events, which are a newer thing that I'm less familiar with, I confess.

[00:12:31]
But it's meant to bridge the gap between clicks and touches. So that you have this one kind of unified way of dealing with touch and click, yeah. But for now, just learn about clicks and keypresses and such.