8.6 DOM Events
DOM events are extremely important. They are what allow us to create compelling, interactive web pages. We’ll see how to use DOM events to react to user and browser events in this lesson.
1.Introduction2 lessons, 07:42
2.Language Fundamentals8 lessons, 1:00:53
3.Data Structures5 lessons, 22:52
4.Controlling Program Execution7 lessons, 37:06
6.Functions8 lessons, 56:07
7.Miscellaneous6 lessons, 52:39
8.Working With the DOM6 lessons, 37:39
9.Web APIs4 lessons, 17:41
11.Conclusion1 lesson, 00:43
8.6 DOM Events
Hi folks! In this lesson, we're gonna see how we can make our pages nicely interactive by responding to events triggered by different elements on the page as users interact with them. Using DOM events is a cornerstone of modern webpage development. In order to make use of events generated in the UI of our web applications, we need to add event handlers for different user actions, like clicks on particular elements. Traditionally, this was a bit of a cross browser headache because IE exposed different methods for attaching events than other browsers. Thankfully these days, all modern browsers use the same API, so it's much easier than it used to be. So let's add an event handler to one of the elements on our test page. So we've now got a reference to the heading on the page, let's add an event listener for click events. So we've added an event list now for click events using the addEventListener method. This method takes two arguments, it can take more, but it’s very commonly used with two arguments. The first argument is the name of the event that we want to listen for, in this case, it's click events. And the second argument is a handler function, in this case, it's an array function. Event handler functions are automatically passed an event object. And we can also log this out to the console as well, so that we can take a look at it. So we should find now that when we click on the heading, we see a message in the console. So the event object was part of our log statement. And let's open that up, and we can see that it contains many, many different properties. And this is all useful information about either the event itself or the element that the event occurred on. For example, we can see the target property down here, and that points to the element that triggered the event, in this case, the heading. The addEventListener method can also accept a third argument, and that specifies whether the event should be handled in the bubbling or the capture phase. Generally, we don't need to worry about this, but it is useful to understand what happens when an event is triggered. So when the H1 element was actually clicked just then, the event traveled from the document down to the target element, which in this case, was the H1. So this is known as the capturing phase. As soon as the event reaches the element that triggered the event, it enters the at-target phase. The event then travels back up from the element that triggered the event all the way back up to the document. And that's the bubbling phase. So as I mentioned, generally we don't need to worry about these different phases. Although, we can make use of the fact that these phases occur in a technique known as event delegation. And that is where we attach event listeners to parent elements instead of individual elements. And we wait for the events to bubble up from the children elements, up to the parent, which contains the handler. So one example is that we might want to add listeners to the list items in a list. So we do have a list on the page. So instead of getting the heading, let's get the list instead. So we've added a click handler to the unordered list. Let's take a look at what happens when we click on any of the list items. We just need to get the first list item out of the collection returns by getElementsByTagName. So we've added the click handler to the list. Not the individual children, but we can still click on the individual child elements. And that will still trigger the event list now on the parents. And if we open up the event object, we can see that the target points to the list item that was clicked. So this can be a very useful technique. So when an element is clicked and triggers an event, even if a parent handles that event, the event will still continue to bubble all the way up to the document. So let's add another click handler to the document. So let's see what happens now. We see both of the log messages. So we see the log message added in the handler for clicks on the list item for clicks on the list. But even once the list has handled that, the click event still travels all the way up to the document element and triggers the handler that we added there. And we don't always want that to happen. Luckily, there is a very easy way to stop the propagation of that event. So we've used the stopPropagation method of the event object. And that will stop the event from travelling any further than this handler. So now, if we click somewhere on the document, we'll see the generic click happened log message. But if we click on one of the child elements, we only see one event now, because the event gets stopped by the handler attached to the list. And it doesn't bubble up any further from that point. The event object has another useful method called preventDefault. This is useful for when the element is an anchor. Usually when an anchor is clicked, the browser's default action is to follow the href of that anchor. And to either navigate to a different part of the same document or a different document altogether. We can stop that default behavior using the preventDefault method. So let's just create a quick anchor and append it to the page. So we've created a new anchor element, we've given it some text, and set its href attribute and we've appended it to the page. And we can see the link down at the bottom of the page here. And if we click on that, it takes us to Google as we would expect. So let's now stop that from happening. So let's go back to the page now. And this time when we click it, the document doesn't take us to Google.com. If we want to remove an event listener, we can use the removeEventListener method. However, for this to be effective, we need to know which handler function we are removing. And so we should use named function references instead of the arrow functions that we've been using so far. So it should still work in exactly the same way as it did before. But now, if we want to remove that handler, we've got a function reference that we can use. And now we shouldn't see any more messages. I accidentally clicked the list then, but when I click the document, the handler has been removed. So in this lesson, we looked at adding listeners, or handlers, for events triggered on the page by the actions of our users. We focused on mouse events, because they're quick and easy to work with. But we can also make use of many other types of events, including keyboard events, and scroll events. We saw how to add event listeners using the addEventListener method. And we saw that we should provide a name for the event that we want to listen to as the first argument. And the function to invoke whenever the event occurs as the second argument. We saw that event handling functions are automatically passed an event object. Which contains useful properties that give us information about the event. And methods that we could use to either stop the event from propagating up the document or to prevent the default behavior of the browser. Lastly, we saw how to remove event listeners with the removeEventListener method. But then we need to specify exactly which listener we want to use, and so this only works with function references and not with anonymous arrow functions. This now brings us to the end of the DOM section. The next section is the final section of the course, and it focuses on using some common web APIs. Thanks for watching.