DOM events: enhance a working control without losing its baseline

Case study

An incident analyst types 'pump 47' and submits. The browser can issue a GET search through the form action. Once the script has attached, the handler fetches a count and reports it in an existing status region. A failed request invokes the form's normal navigation path. The script uses textContent rather than inserting untrusted HTML. Pressing Enter in the input and activating the button both use the same submit event. A click-only handler on the button would miss the keyboard path and could fail when another submit control is added.

Working contract

<form id="case-search-form" action="/cases" method="get">
  <label for="case-search-term">Case terms</label>
  <input id="case-search-term" name="term" required maxlength="80">
  <button type="submit">Search cases</button>
</form>
<p id="case-search-status" role="status"></p>
<script>
  const searchForm = document.querySelector("#case-search-form");
  const searchStatus = document.querySelector("#case-search-status");
  searchForm.addEventListener("submit", async (event) => {
    const searchTerm = searchForm.elements.term.value.trim();
    if (!searchTerm) return;
    event.preventDefault();
    searchStatus.textContent = `Searching for ${searchTerm}`;
    try {
      const query = new URLSearchParams({ term: searchTerm });
      const response = await fetch(`/cases?${query}`);
      if (!response.ok) throw new Error(`HTTP ${response.status}`);
      const result = await response.json();
      searchStatus.textContent = `${result.total} cases found`;
    } catch {
      searchForm.submit();
    }
  });
</script>

Cost and tradeoffs

The handler performs direct DOM lookups at initialization and O(L) query construction per submit, where L is the encoded term length. Delegating a large table of controls to one parent can reduce listener count from O(N) to O(1), but target matching still occurs on each event. Network latency and JSON parsing dominate this small handler. The status node remains stable instead of rebuilding the whole page. A full results view would also need an empty state and a way to prevent an older response from overwriting a newer one.

Common Mistakes

• Do not make a button click the only path for form submission.
• Do not call preventDefault before an enhanced path can handle the task.
• Do not place untrusted search text into innerHTML.
• Do not remove the form action merely because JavaScript is expected to run.

Continue through the stack

HTML forms: choose GET for retrieval and POST for a state change; HTML labels: bind each control to a durable accessible name; HTML status region: announce a changed result without stealing focus; JavaScript Tutorial.

Failure trace

A search works when the button is clicked but fails when the user presses Enter. Its script listens to click on one button, then cancels navigation before it knows whether the API is available. Keep a real form action and handle submit, which covers both keyboard and pointer activation. If the enhanced request fails, let the browser follow the form's normal route with the entered values intact.

Verification

• Submit the same query with Enter and the button; compare the resulting request.
• Disable JavaScript and confirm the native form still reaches useful results.
• Make the enhanced fetch fail and confirm the fallback does not erase the entered term.

Decision note

One stable form handler is usually enough. Event delegation helps when controls are inserted later, but it does not excuse vague target checks or replacing semantic controls with clickable text.

Further connections

Event Loop Tasks, Microtasks, and Paint.