Events

An event is the browser telling you something happened: a click, a key press, a form submission, a field losing focus. You register interest in a particular event on a particular element, and the browser calls your function when it occurs.

That is the whole mechanism. The parts that need care are which element to listen on, and remembering to stop listening.

const form = document.querySelector("#expense-form");

form.addEventListener("submit", (event) => {
  event.preventDefault();

  const fields = new FormData(form);
  const amount = Number(fields.get("amount"));

  if (!Number.isFinite(amount) || amount <= 0) {
    showError("Enter an amount greater than zero.");
    return;
  }

  addExpense({
    description: fields.get("description"),
    amount,
  });

  form.reset();
});

• addEventListener takes the event name and a function to call. The name is a plain string and is case-sensitive: "submit", not "onSubmit".
• The function receives an event object describing what happened. Here it is used for one thing, and there is more on it below.
• preventDefault stops the browser's built-in response. For a submit event that response is sending the form and loading a new page, which is not what you want when the page is updating itself.
• Listening for submit rather than for a click on the button is deliberate. submit also fires when someone presses Enter in a text field, so the keyboard path works with no extra code.
• FormData reads the fields by their name attribute — the same names from the forms lesson, which is why those names matter.
• Returning early after showing an error keeps the failure path short and obvious.

Events travel upwards. When you click a button inside a row inside a list, the event does not only happen at the button. After the button, the browser offers it to the row, then the list, then their ancestors, up to the document. This is called bubbling.

Two useful consequences. A listener on an ancestor sees events from everything inside it. And the event object tells you both where you are listening (event.currentTarget) and what was actually clicked (event.target).

That is what makes the next pattern possible, and it is the one worth learning properly.

const list = document.querySelector("#expense-list");

list.addEventListener("click", (event) => {
  const approveButton = event.target.closest("button[data-action='approve']");

  if (!approveButton) {
    return;
  }

  const row = approveButton.closest(".expense-row");
  approveExpense(row.dataset.expenseId);
});

• The listener is on the list, not on the buttons. One listener, however many rows there are.
• event.target is the deepest element the click landed on, which might be an icon inside the button rather than the button itself.
• closest walks up from there looking for the first ancestor that matches the selector, including the element itself. So a click on the icon still finds the button.
• When closest finds nothing, the click was somewhere else in the list and there is nothing to do. Guarding first keeps the rest of the handler simple.
• The row's id comes from its data attribute, so the handler works for any row without needing a reference to it.
• The important part: rows added, removed or re-rendered later are covered automatically, because the listener was never on a row. Attaching a listener per button means re-attaching after every render, and forgetting once produces buttons that look fine and do nothing.