Pocket can draw its list. Now people want to do things to it: delete an expense, mark one as reviewed, filter by category. Each of those starts with the user doing something, such as clicking or typing, and your code reacting. The browser reports everything users do as events.
\nYou ask an element to tell you about an event with addEventListener:
const clearButton = document.querySelector(\"#clear\");\n\nclearButton.addEventListener(\"click\", (event) => {\n console.log(\"Clear was clicked\", event.type);\n});Read it as: “when a click happens on this button, call this function”. Your function does not run now. The browser stores it and calls it later, once per click, passing an event object with details about what happened. This is the callback idea from the functions lesson, and the browser is the code calling you back.
\nThe event types you will use most: click, input (a text field’s value changed), change (a value was committed, for example a select), submit (a form was sent), and keydown (a key was pressed; event.key says which, such as "Enter" or "Escape").
The most important habit with events: do not treat the page as the place your data lives. Keep the data in a variable, change the variable in your handler, and call the render function from the last lesson to redraw:
\nlet expenses = [\n { id: \"exp-1\", label: \"Coffee\", amount: 450 },\n { id: \"exp-2\", label: \"Train\", amount: 1220 },\n];\n\nclearButton.addEventListener(\"click\", () => {\n expenses = [];\n renderExpenses(expenses);\n});The handler never touches <li> elements directly. It changes the data, and the render function makes the page match. However many buttons you add, there is still one place that draws the list, so the total and the list can never disagree.
When you click a button inside a list item inside a list, you are clicking all of them: the button, the <li>, the <ul>, the <body>. The browser models this by delivering the event first to the element you clicked, the target, and then to each ancestor in turn, all the way up to document. This is called bubbling.
Inside a handler, event.target is the element where the event started, and event.currentTarget is the element whose listener is running now. A listener on the <ul> therefore hears clicks on every button inside it and can still find out which button it was.
Suppose every expense has a delete button. You could attach a listener to each button, but the render function throws those buttons away and makes new ones every time the list changes, and the new buttons have no listeners. Instead, attach one listener to the list, which is never replaced, and work out what was clicked:
\nconst list = document.querySelector(\"#expense-list\");\n\nlist.addEventListener(\"click\", (event) => {\n const button = event.target.closest(\"button.delete\");\n if (!button) {\n return; // the click was somewhere else in the list\n }\n const id = button.closest(\"li\").dataset.id;\n expenses = expenses.filter((e) => e.id !== id);\n renderExpenses(expenses);\n});closest(selector) starts at an element and walks up through its ancestors until it finds one that matches, or returns null. That handles clicks on an icon inside the button, and the if (!button) guard ignores clicks on the rest of the item. The id comes from the data-id you set while rendering, and the data change is a filter, exactly as in section 3.
This pattern is called event delegation. It means fewer listeners, and it keeps working for items added after the listener was set up, because their clicks bubble to the same list.
\n\nTo stop a click from bubbling further you can call event.stopPropagation(), but you will rarely need it, and using it often breaks delegation somewhere else. event.preventDefault() is different and far more common: it cancels the browser’s default action, such as following a link or submitting a form. That second one is the star of the next lesson.
addEventListener(type, handler) registers a function the browser calls later, with an event object describing what happened.","Pass the handler itself, without parentheses; writing handler() calls it immediately and registers its return value instead.","Events bubble from the element that was clicked up through its ancestors, so a listener on a parent hears clicks on its children.","With event delegation, one listener on a container uses event.target.closest(...) to find which item was clicked, including items added later.","Keep data in variables, change the data in handlers, then call your render function; never treat the page as the source of truth."],"further":[{"title":"Introduction to events (MDN)","url":"https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/Scripting/Events"},{"title":"EventTarget.addEventListener() (MDN)","url":"https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener"},{"title":"Event bubbling (MDN)","url":"https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/Scripting/Event_bubbling"}],"quiz":[{"q":"What is wrong with button.addEventListener("click", deleteExpense());?
deleteExpense runs once immediately, and its return value (probably undefined) is registered instead of the function.","why":"Correct. Pass the function itself, deleteExpense, or wrap it, () => deleteExpense(id), so the browser calls it on each click."},{"text":"Buttons cannot have click listeners; only links can.","why":"Any element can have a click listener, and buttons are the right element for actions."}],"answer":1},{"q":"A list item contains <span>Coffee</span> <button class="delete">×</button>. The listener is on the <ul>. A user clicks the button. What are event.target and event.currentTarget?
<ul>.","why":"currentTarget is the <ul>, but target is the element that was actually clicked."},{"text":"target is the <ul> and currentTarget is the button.","why":"It is the other way round. target is where the event started; currentTarget is where the listener is."},{"text":"target is the button and currentTarget is the <ul>.","why":"Correct. The click started on the button and bubbled up to the <ul>, whose listener is now running."}],"answer":2},{"q":"Why does a delegated listener keep working for expenses added after the page loaded?
","options":[{"text":"The browser copies listeners to every new child automatically.","why":"Listeners are never copied. Each one stays exactly where you attached it."},{"text":"The listener is on the container, which never changes, and clicks on any child bubble up to it.","why":"Correct. New items are inside the same container, so their clicks reach the same listener."},{"text":"Delegated listeners run again every time the DOM changes.","why":"Listeners only run when their event happens. Nothing re-runs on DOM changes."}],"answer":1},{"q":"Inside a delegated click handler, why use event.target.closest(".delete") rather than checking event.target.classList.contains("delete")?
closest is faster than classList.","why":"Speed is not the issue; both are instant. The issue is which element the click lands on."},{"text":"classList does not work on elements inside a list.","why":"classList works on every element. The problem is that the target may be a child of the button."},{"text":"The click may land on an element inside the button, such as an icon, and closest walks up to find the button anyway.","why":"Correct. closest checks the element itself and then each ancestor, returning the first match or null."}],"answer":2}],"exercise":{"kind":"web","mode":"dom","starter":{"html":"Each expense has a Delete button. The starter attaches a listener to each button, but renderExpenses replaces the buttons after the first delete, so the second delete does nothing, and new expenses can never be deleted.
Replace the loop at the bottom with one click listener on #expense-list. When a click lands on (or inside) a .delete button, remove that expense from expenses using the item’s data-id, then call renderExpenses(). Clicks elsewhere in the list must do nothing.
list.addEventListener("click", (event) => { … });.","event.target.closest(".delete") gives the button, or null if the click was not on one. Return early when it is null.","The id is on the <li>: button.closest("li").dataset.id. Then expenses = expenses.filter((e) => e.id !== id); and renderExpenses();."],"explanation":"The list element is created once by the HTML and never replaced, so a listener on it survives every render. Clicks on any Delete button bubble up to it, including buttons for expenses that did not exist when the listener was added. closest(".delete") finds the button even if the click landed on something inside it, and returns null for clicks on the label, which the early return ignores. The handler changes only the data and then re-renders, so the list and the total always agree with expenses.