Hasty Treat - Things You Should Know About Javascript Events

welcome to Syntax.

On this Monday, hasty treat. We're gonna be talking about JavaScript events, which is definitely a topic that could trip up a ton of people for various reasons.

And so, hopefully, this is going to be pnpm extremely useful topic for you if you write JavaScript at all. My name is Scott Tolinski. I'm a developer from Denver, Colorado. And with me, as always is the Wes Bos.

Hey, everybody. Today, we are sponsored by Prismic, which is a headless CMS. It has a GraphQL API and a Wes API.

So for the next project that you take on, if you need some sort of back end service for it, check out Prismic at prismic.i0.

You can go in. You create all your content types. You can relate them to each other. And then out on the other end, they'll give you this nice interface for working with your data. And then on the other end, you'll be able to pull that data out with either a REST API or a Graph API.

For the nifty, check out prismic.i0forward/syntax.

They've got a bunch of different starters there, one for Vue, Node for React. They've done this hilarious little landing page that's specifically for syntax. So, even if you're not interested and you wanna laugh, check out frismic.i0 forward slash syntax, they say. So it looks like podcasting podcast advertising works. Yeah. That's the headline.

Love it. Cool. So let's get into it.

These are just, like, sort of a handful of things about JavaScript events that I find are useful to understand how they work. And from my JavaScript thirty course, my beginner JavaScript course, These are things that people say, ah, like, I never totally understood how that worked or why that worked that way until I until I took it. So I've taken some of my favorite things from that in order to distill it into, I don't know, 5 or 6 things you should know about JavaScript events.

I love it. So let's get into it. 1st one we have here is bubbling event bubbling. That's something you hear all the time. It's actually kinda Node. Nice thing. It bubbles.

So what is event bubbling? Well, when you have an event in JavaScript so most common would be a click event.

When you click on something, that event will bubble up, meaning that if you have, like let's say you've got a strong tag inside of a button, inside of a card, inside of a a nav, inside of a a web browser, inside of a a computer, inside of the universe inside of the world inside of the universe, then what happens is Yeah. It's only the multiverse.

The Keep going. Wes you click on that button, you are inadvertently also clicking on things that are inside that button as well as things that contain that button.

So when you click on something like a strong tag, the event happens on that strong tag. But then, what happens is that the ESLint, if nothing happens with that event, it bubbles up to the next level, which is a button. And then if nothing was, like, listening for that specific event, then it will bubble up to a higher level and keep bubbling up, basically saying, like, hey.

Somebody clicked me. I thought it was the button, but nothing happened. So I'm going up a a level higher.

And if anyone's interested in the fact that I got clicked, I'm sort of doing the rounds right now, seeing if anyone cares.

And that's what that's what event bubbling JS, meaning that most events in JavaScript, clicks, mouse moves, hovers, things like that, they'll happen on a specific element, but they also will happen on on parent elements.

Now Vercel conversely, is that a word? On on the flip side to that Vercel.

Inversely, you have event capturing.

So the easiest way I can explain what capturing is is that events, they capture down and bubble up. And what that means is that when an event happens, generally, they start at the very lowest element and bubble themselves up. Like, we talked about that.

But the process of figuring out what got clicked on the way down to that is called capturing. So the the way that the browser actually does it is you click on that span. The browser says, oh, they clicked on the window, but they also clicked on HTML. And they also clicked on Bos, and they also clicked on 4 or 5 divs on the way there. And they also clicked on the button. They also clicked on a span inside of that button. So that going from the top down is called capturing.

And when you add an event listener to something, you can specify that you want the event listener to trigger either on the capture phase, which is top down, or on the bubble phase, which is down up. And almost always, I would say 99.99% of the time, you want bubbling, and that's the default. Yeah. I was gonna say, man. If for some reason you wanted to stop the event at a higher level, then you can listen for the event on the capture phase, which is when it comes down instead of on the way up. So there's just a little option that you can pass your at event listeners,

that will allow you to Curious. I'm wondering what the use use case is there for that. Yeah. So, like, if you have, like,

an event listener on 2 different things like, let's say, you have a button inside of a, like, a widget that is draggable and droppable.

You might want to listen for, like, a drag event on the card itself and stop that from happening before the person actually accidentally clicks something that is inside of that card. Right? Mhmm. So if that was the case, then you would listen on capture down and then stop that event from happening, which is called prevent default. I'll get into that next. Mhmm. And then what happens is that event never gets all the way down to the lower elements, and that that causes you from stops you from accidentally clicking something inside of that

widget. Interesting.

So do you wanna move on to prevent default? Yeah. So I think prevent default might be one of these things that people are familiar with the moment that they start using React or any front end framework, and they're working with a form specifically. Right? I mean, there's there's all sorts of ways where prevent default comes in handy. But let's say you're working with a form, you do on submit, the whole page refreshes, and then you say, oh, my page refreshed Wes I submit the form. You Google that, and then people say, oh, well, you need to take the event and do event dot prevent default, preventing, of course, the default behavior. But do you wanna talk a little bit more about prevent default?

Yeah. Well, I I think that's pretty much it JS that some HTML elements have defaults.

When links are clicked, they change the page. When forms are submitted, they get that data to whatever URL it has the action on that form, and those are all defaults. That's just functionality that's built into the browser.

But if you wanted to stop that for whatever reason, maybe you're putting your own custom functionality into a form submit like most of us do. And if that's the case, then you just stop the default with event dot prevent default, and that will stop the default from happening. And then it's your job as the developer to step in and and do the work and and make sure that that works like that. Totally.

What else do we have here? The difference between target and current target. You know the do you know the difference here, Scott?

I always forget it. I do not. I've only I only use target. Like, I never I've never used current target.

Yeah. So the difference between target and current target is, current target is what actually got clicked, and target is what you listened for a click on. So the difference there being that if you let's use a button with a, like, a strong tag inside of that. If you click on a button you you listen for a click on a button, and then you you run a callback when that got clicked. Target would be the button. That's probably what you wanted. Right? And then current target is the actual element that got clicked before that click bubbled up to the parent element and then trigger to click on that. So, sometimes you need to know, did the user click something that was inside of this thing and then that thing bubbled up? Or sometimes you just wanna know, did they did they click the button? So most common thing I use current target and target for is, event delegation. So sometimes if you attach an event listener to let's say you have, a div that's full of 7 or 8 buttons, and those buttons are being added and removed as you do things on the page. If you are using target there, then you have to, like, keep track of the event listeners on every single button that's added and removed, where what you can do is you could just listen for a click on the div that contains all of those buttons.

And then every time that div is clicked, you can check if the current target was a button, meaning that you have 1 event listener on the entire div, and then the target there would be a div. But you can check if the thing that they actually clicked was indeed a button. And if that's the case, then you have 1 event listener for the entire thing, and that that's what's referred to as, event delegation, which is pretty nifty. Interesting.

Yeah. I use that one a lot because, specifically, in vanilla JavaScript, you have to, like, take care of adding and removing event listeners yourself, which is such a pain in the butt. That's why frameworks like React are so nice because you don't have to worry about any of this. Mhmm. But if you're using vanilla JavaScript, you have to add the event listeners and remove them when the element gets removed and such a pain. So, actually, React uses this in React. They actually have 1 one event listener on the I think it's the HTML tag.

And when a click or any event happens on the HTML tag, it actually delegates it under the hood. That's why React events are called synthetic events. Right. Yeah. Because under the hood, they're they're using event delegation as well. Apparently, it's it's more performant just to have 1 event listener and then delegate it out with the current target. Yeah. I know that's something that's been a bit of a not recently, but in general, a bit of a topic in React land.

Yeah. Yeah.

What else do we have here? Event dot is trusted. This is something that I've done before because we built a whack a mole game in my JavaScript thirty, and we also learned how to fake clicks and fake triggering events in in JavaScript.

So if you ever want to know if an event was actually fired by a user action and not a custom dispatched event, then you can check if the is trusted Boolean is set to true or false. So that will tell you, did somebody actually click this button, or did somebody fake a click that made it it happen?

Interesting.

Yeah. And then finally, we have the add add event listener once of true. So this is an option you can pass the event listener where it will unbind itself. It will it'll remove the event listener after it's called once. Once.

So for I don't have a a bunch of ideas off the top of my head, but a lot of times, you just like, when someone clicks a button, do this thing the first time, like, fade in this thing or do an animation, and then after that, don't do that every single time that they clicked it. So you have to remove the ESLint listener. So adding once of true, this JS something we had in jQuery for years. It was great. It'll just remove itself, and there's there's no cleanup needed there.

These are all things that, like, I feel like you come across them when you start working in a lot of vanilla. In the moment Yeah. That you're outside of vanilla, you might not hit a lot of these issues or instances. So think this is really fascinating, especially as somebody who works primarily in frameworks to learn a little bit more about events.

Yeah. It's it's good to know, like, the stuff, like, under the hood. That's kinda why I wanted to do this this thing. You might not use it every single day, but it's good to know how it actually is happening because, certainly, React is using this stuff under the hood.

But it's I would say with the exception of the targets and the bubbling, I don't run into a whole lot of these things when you're using a framework because they they sort of simplify that all for you. Yeah. Cool. Well, do you have anything else on events here? That's all I've got. I don't know. If you have other stuff, make sure you tweet us at syntax f m, and, we'd like to hear your little gotchas and and neat things that you know about events. Yeah. That that'd be great. We'll re we'll, hit hit you up with a retweet.

Alright. Thanks for tuning in. Catch you on Wednesday.

Peace.

Peace.

Head on over to syntax.fm for a full archive of all of our shows, and don't