⚡ Event Handling in React

Why Events Matter

Think of an event as a doorbell. Someone presses it (a user clicks, types, or scrolls), a wire carries the signal, and a bell rings somewhere inside the house (your code runs). React's job is to make that wiring simple and consistent — you say "when this button is clicked, run this function," and React handles the browser plumbing underneath.

Every interactive feature you'll build — search boxes, dropdowns, drag-and-drop, forms — is an event handler that updates state. And because updating state re-renders the component, the loop from action to UI change is the heartbeat of a React app.

Attaching Handlers

In plain HTML you'd write onclick="doThing()" — a lowercase attribute holding a string. React changes two things: the prop is camelCase (onClick), and you pass an actual function, not a string.

function ButtonExample() {
  // Define the handler once, inside the component.
  function handleClick() {
    alert('Button clicked!');
  }

  // Pass the function REFERENCE — note: handleClick, not handleClick()
  return <button onClick={handleClick}>Click me</button>;
}

Inline arrow functions

For short, throwaway logic you can define the handler right in the JSX with an arrow function:

function InlineExample() {
  return <button onClick={() => alert('Clicked!')}>Click me</button>;
}

This is fine for tiny handlers. When the logic grows past a line or two, pull it out into a named function — it reads better and is easier to debug.

A real handler that updates state

import { useState } from 'react';

function Counter() {
  const [count, setCount] = useState(0);

  // Using the updater form keeps us correct even with rapid clicks.
  const increment = () => setCount(c => c + 1);

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={increment}>+1</button>
    </div>
  );
}

This is the pattern behind almost everything: an event handler calls setState, and React re-renders with the new value.

Passing Arguments to Handlers

Often you need to tell the handler which thing was acted on — which item in a list, which tab, which id. Since onClick wants a function reference, you wrap your call in an arrow function so it runs only when clicked:

function ItemList() {
  const items = [
    { id: 1, name: 'Apples' },
    { id: 2, name: 'Bread' },
    { id: 3, name: 'Coffee' },
  ];

  const handleSelect = (id) => {
    console.log(`Item ${id} selected`);
  };

  return (
    <ul>
      {items.map((item) => (
        // The arrow defers the call: handleSelect runs on click, not on render.
        <li key={item.id} onClick={() => handleSelect(item.id)}>
          {item.name}
        </li>
      ))}
    </ul>
  );
}

Getting both the argument and the event

Need the event object and a custom argument? The wrapper arrow receives the event and forwards both:

const handleSelect = (id, e) => {
  console.log('Selected', id, 'via', e.type);
};

<li onClick={(e) => handleSelect(item.id, e)}>{item.name}</li>

The Event Object

Every handler receives an event object (conventionally named e or event). It carries details about what happened: which element, which key, whether Shift was held, and more.

function EventInspector() {
  const handleClick = (e) => {
    console.log('type:', e.type);            // "click"
    console.log('target:', e.target);        // element actually clicked
    console.log('currentTarget:', e.currentTarget); // element with the handler
    console.log('coords:', e.clientX, e.clientY);   // mouse position
    console.log('modifiers:', e.shiftKey, e.ctrlKey, e.altKey);
  };

  return <button onClick={handleClick}>Inspect me</button>;
}

Keyboard events

Keyboard handlers give you the human-readable e.key. Prefer it over the deprecated numeric e.keyCode:

function SearchBox() {
  const handleKeyDown = (e) => {
    if (e.key === 'Enter') {
      console.log('Search submitted');
    }
    if (e.key === 'Escape') {
      e.currentTarget.blur(); // dismiss on Escape
    }
  };

  return <input type="text" onKeyDown={handleKeyDown} placeholder="Search…" />;
}

Preventing Default Behavior

Browsers have built-in reactions: submitting a form reloads the page, clicking a link navigates away, right-clicking opens a context menu. When your component wants to handle those itself, call e.preventDefault() to cancel the browser's default.

function CommentForm() {
  const [text, setText] = useState('');

  const handleSubmit = (e) => {
    e.preventDefault();          // stop the full-page reload
    console.log('Submitting:', text);
    // …send to an API, update state, etc.
    setText('');
  };

  return (
    <form onSubmit={handleSubmit}>
      <input
        value={text}
        onChange={(e) => setText(e.target.value)}
        placeholder="Write a comment"
      />
      <button type="submit">Post</button>
    </form>
  );
}

Propagation: Bubbling & Capturing

When you click a button nested inside a couple of <div>s, the event doesn't only fire on the button. It travels: first down from the document to the target (the capturing phase), then back up from the target to the document (the bubbling phase). Handlers on ancestors fire along the way.

Stopping propagation

By default a click on the inner element also triggers handlers on its parents (bubbling). Call e.stopPropagation() to keep the event from travelling further up:

function NestedClicks() {
  const handleOuter = () => console.log('Outer clicked');

  const handleButton = (e) => {
    e.stopPropagation();     // outer handler will NOT fire
    console.log('Button clicked — and stopped here');
  };

  return (
    <div onClick={handleOuter} style={{ padding: 20 }}>
      Outer area
      <button onClick={handleButton}>Click me</button>
    </div>
  );
}

Listening in the capture phase

Add Capture to any handler name to run it on the way down instead of up:

<div
  onClickCapture={() => console.log('Outer capture — fires first')}
  onClick={() => console.log('Outer bubble — fires last')}
>
  <button onClick={() => console.log('Button — fires in the middle')}>
    Click
  </button>
</div>
// Order: "Outer capture" → "Button" → "Outer bubble"

Efficient Handlers

Defining a handler inside a component means a brand-new function is created on every render. For most components that's completely fine — function creation is cheap. It only becomes worth optimizing when the handler is passed to many memoized children that would otherwise re-render needlessly.

Stable references with useCallback

import { useState, useCallback, memo } from 'react';

// memo skips re-rendering when props are unchanged…
const ItemButton = memo(function ItemButton({ id, name, onSelect }) {
  console.log('render', name);
  return <button onClick={() => onSelect(id)}>{name}</button>;
});

function Toolbar() {
  const [selected, setSelected] = useState(null);

  // …so we keep onSelect stable across renders with useCallback.
  const handleSelect = useCallback((id) => {
    setSelected(id);
  }, []);

  const items = [
    { id: 'a', name: 'Bold' },
    { id: 'b', name: 'Italic' },
  ];

  return items.map((item) => (
    <ItemButton key={item.id} id={item.id} name={item.name} onSelect={handleSelect} />
  ));
}

One handler for many children (delegation)

Instead of attaching a handler to every list item, attach one to the parent and read e.target to see what was clicked. Data attributes carry the id:

function TodoList({ todos }) {
  const handleClick = (e) => {
    const id = e.target.dataset.id;   // reads data-id from the clicked <li>
    if (id) console.log('Toggled todo', id);
  };

  return (
    <ul onClick={handleClick}>
      {todos.map((t) => (
        <li key={t.id} data-id={t.id}>{t.text}</li>
      ))}
    </ul>
  );
}

React actually uses delegation internally — but doing it explicitly like this can simplify very large or frequently changing lists.

Practice & Quiz

function Counter() {
  const [count, setCount] = useState(0);

  const handleClick = (e) => {
    // TODO: if e.shiftKey, subtract 1; otherwise add 1
  };

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={handleClick}>Click (Shift to subtract)</button>
    </div>
  );
}

const handleClick = (e) => {
  const step = e.shiftKey ? -1 : 1;
  setCount((c) => c + step);
};

function Modal({ onClose, children }) {
  return (
    <div className="backdrop" onClick={onClose}>
      <div
        className="dialog"
        onClick={(e) => e.stopPropagation()} // clicks inside stay inside
      >
        {children}
        <button onClick={onClose}>Close</button>
      </div>
    </div>
  );
}

Best Practices & Pitfalls

✅ Do

• Pass a function reference (onClick={handleClick}), or a wrapper arrow when you need arguments
• Handle submissions with onSubmit on the <form> plus e.preventDefault()
• Use e.key (e.g. 'Enter', 'Escape') for keyboard logic, not the deprecated keyCode
• Name handlers handleX and the props onX for readable, conventional code

❌ Don't

• Call the handler in JSX: onClick={handleClick()} fires it once at render, not on click
• Reach for useCallback/memo everywhere — optimize only measured hotspots
• Confuse stopPropagation() (stops other handlers) with preventDefault() (stops browser default)
• Forget accessibility: make clickable non-buttons keyboard-reachable, or just use a <button>

// ❌ Reads a possibly stale count
const bad = () => setCount(count + 1);

// ✅ Updater form always sees the latest value
const good = () => setCount((c) => c + 1);

Summary

📚 Additional Resources

• React docs — Responding to Events
• React docs — The React event object
• MDN — Introduction to events

🚀 What's Next?

You've been using that mysterious e object all lesson. Next we lift the hood: Synthetic Events — how React normalizes browser differences, delegates from the root, and what changed when event pooling was removed in React 17.