Handling Events in React

If you learned HTML first, you probably wrote onclick="doSomething()" — a lowercase attribute holding a string of JavaScript. React looks similar but works differently in three important ways, and mixing them up is the #1 source of beginner event bugs.

<!-- Plain HTML: lowercase attribute, string of code -->
<button onclick="handleClick()">Click me</button>

// React JSX: camelCase prop, function reference
<button onClick={handleClick}>Click me</button>

Ang importante dito: in React you hand over the function itself (handleClick, walang parentheses) and React calls it for you when the event fires. If you write handleClick(), you are calling it right now, during render — we will see that bug live in Section 3.

The smallest useful event: a button that counts its own clicks. Three steps, and this exact shape covers 80% of the event handling you will ever write.

Click the button in the Demo tab, then open the Code tab. The flow is always the same: an event fires → your handler runs → the handler calls a state setter → React re-renders with the new value. That loop — event → state → render — is the heartbeat of every React app.

Sooner or later you need to tell the handler which item was clicked — which fruit, which product, which row. The instinct is to write onClick={handlePick(fruit)}. Here is what that actually does:

// ❌ BROKEN: handlePick runs immediately, during render — not on click!
export function FruitPicker() {
  const [picked, setPicked] = useState('');

  const handlePick = (fruit: string) => {
    setPicked(fruit); // setting state during render...
  };

  return (
    <div>
      {/* This CALLS handlePick('Mango') while rendering. */}
      {/* Setting state during render triggers another render, */}
      {/* which calls it again... hello, infinite loop: */}
      {/* "Too many re-renders. React limits the number of renders */}
      {/*  to prevent an infinite loop." */}
      <button onClick={handlePick('Mango')}>Mango</button>
    </div>
  );
}

The fix: wrap the call in an arrow function. Now you are passing a new small function whose body only runs when the click actually happens.

// ✅ FIXED: pass a function that, WHEN CALLED, runs handlePick('Mango')
<button onClick={() => handlePick('Mango')}>Mango</button>

Every handler receives an event object (by convention named e) as its first argument. React passes it automatically — you don't do anything special to get it.

export function EventInspector() {
  // React passes the event object automatically
  const handleClick = (e: React.MouseEvent<HTMLButtonElement>) => {
    console.log(e.type);          // "click"
    console.log(e.currentTarget); // the <button> the handler is attached to
    console.log(e.target);        // the exact element that was clicked
    console.log(e.clientX, e.clientY); // mouse position in the viewport
  };

  return (
    <button onClick={handleClick}>
      <span>Icon</span> Inspect me
    </button>
  );
}

The pair that confuses everyone: e.target vs e.currentTarget. In the button above, clicking the <span> inside it makes e.target the span (what you actually hit) while e.currentTarget is always the button (what the handler is attached to). Rule of thumb: reaching for the element you attached the handler to? Use currentTarget. Reading an input's value in onChange? e.target.value is the idiom.

If you write TypeScript, React ships precise types for each event family — your editor then autocompletes exactly the right properties:

// Mouse events (click, double-click, mouse enter/leave)
const handleClick = (e: React.MouseEvent<HTMLButtonElement>) => {
  console.log(e.clientX, e.clientY);
};

// Change events (inputs, selects, textareas)
const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => {
  console.log(e.target.value); // typed as string ✨
};

// Form submission
const handleSubmit = (e: React.FormEvent<HTMLFormElement>) => {
  e.preventDefault();
};

// Keyboard events
const handleKeyDown = (e: React.KeyboardEvent<HTMLInputElement>) => {
  console.log(e.key); // "Enter", "Escape", "a", "ArrowDown"...
};

// Focus events
const handleBlur = (e: React.FocusEvent<HTMLInputElement>) => {
  console.log('left the field with value:', e.target.value);
};

Forms are where events earn their keep. Two events do almost all the work: onChange fires on every keystroke (unlike plain HTML's change event, which waits for blur), and onSubmit fires when the form is submitted — by the button or by pressing Enter inside a field.

Try it: type your name and press Enter — the form submits without touching the button, dahil onSubmit lives on the <form>, hindi sa button. That's also why you put the handler on the form, not onClick on the submit button.

Keyboard events level up your UX: Enter to add an item, Escape to close a modal, arrow keys to navigate a dropdown. The workhorse is onKeyDown, and the property you check is e.key — a readable string like "Enter", "Escape", or "ArrowDown".

Type a skill and press Enter — no form, no button, just onKeyDown checking e.key === "Enter". Notice the guard clauses: bail out early on the wrong key, an empty draft, or a duplicate tag. Early returns keep handlers flat and readable.

Beyond clicks, two event pairs power a huge amount of everyday UI polish:

• onMouseEnter / onMouseLeave — fire once when the pointer crosses the element's boundary. Tooltips, hover cards, preview states.
• onFocus / onBlur — fire when an element gains or loses keyboard focus. The classic use: validate a field when the user leaves it, not on every keystroke.

When you click an element, the event doesn't stop there — it bubbles up through every ancestor, firing their handlers on the way. Click a button inside a card inside a page, and any onClick on the button, the card, and the page will all run, innermost first.

See it yourself: click the inner box below and watch the log — both handlers fire, inner first, then outer. Then tick the checkbox to call e.stopPropagation() and click again: the bubble stops at the inner box.

Where you meet this in real life: a "delete" button inside a clickable list row. Clicking delete also triggers the row's "open" handler — unless the delete handler calls e.stopPropagation().

export function ListRow({ item, onOpen, onDelete }: ListRowProps) {
  return (
    <li onClick={() => onOpen(item.id)}>
      {item.title}
      <button
        onClick={(e) => {
          e.stopPropagation(); // don't let the click reach the row's onClick
          onDelete(item.id);
        }}
      >
        🗑 Delete
      </button>
    </li>
  );
}

Time to combine everything into one real component. A star rating widget uses two event types driving two pieces of state: onClick locks in the rating, while onMouseEnter / onMouseLeave drive a temporary hover preview.

Hover across the stars (preview updates live), then click one (the rating sticks even after the mouse leaves). Open the Code tab and study the shown = preview || rating line — the entire "hover overrides saved rating" behavior is that one expression. Konting state, tamang events, malinis na UX.

// ❌ BAD: runs during render; if it sets state → infinite loop crash
<button onClick={handleDelete(item.id)}>Delete</button>

// ✅ GOOD: pass the function itself, or an arrow wrapper for arguments
<button onClick={handleReset}>Reset</button>
<button onClick={() => handleDelete(item.id)}>Delete</button>

// ❌ BAD: all three calls read the SAME count from this render.
// If count is 0, each line computes 0 + 1 → final result is 1, not 3.
const handleTripleClick = () => {
  setCount(count + 1);
  setCount(count + 1);
  setCount(count + 1);
};

// ✅ GOOD: the updater form receives the latest value each time → 3
const handleTripleClick = () => {
  setCount((c) => c + 1);
  setCount((c) => c + 1);
  setCount((c) => c + 1);
};

// ❌ BAD: the page reloads on submit and your state is gone
const handleSubmit = (e: React.FormEvent<HTMLFormElement>) => {
  saveUser(name);
};

// ✅ GOOD: cancel the browser default first
const handleSubmit = (e: React.FormEvent<HTMLFormElement>) => {
  e.preventDefault();
  saveUser(name);
};

// ❌ OUTDATED: the old class-components way — you had to bind `this`
class Counter extends React.Component {
  constructor(props) {
    super(props);
    this.handleClick = this.handleClick.bind(this); // 2018 called...
  }
  handleClick() {
    this.setState({ count: this.state.count + 1 });
  }
}

// ✅ MODERN: function components have no `this` to bind. Ever.
export function Counter() {
  const [count, setCount] = useState(0);
  const handleClick = () => setCount((c) => c + 1);
  return <button onClick={handleClick}>{count}</button>;
}

If a tutorial tells you to .bind(this) in a constructor, it's teaching the pre-hooks class era. In function components, this-binding simply doesn't exist as a problem — one more reason the ecosystem moved on.

Your scannable reference — the event props you will actually use, week one to week fifty:

Cement everything with one small build — an emoji reaction bar like the ones under a Facebook post:

• Render 4 reaction buttons (👍 ❤️ 😂 😮) from an array — onClick={() => react(emoji)} with the arrow-wrapper pattern
• Each click increments that emoji's count — store counts in one state object, update immutably
• onMouseEnter shows a label ("Haha", "Wow") above the hovered button; onMouseLeave hides it
• Add a comment input: onChange tracks the draft, onKeyDown submits on Enter, and the whole thing lives in a form with preventDefault
• Stretch goal: put the bar inside a clickable card and use stopPropagation() so reacting doesn't open the card

If you can build that without peeking back, event handling is officially in your muscle memory. 💪

Keep practicing! 💪 Events are where React stops being pictures on a screen and starts being an app. Once event → state → render feels automatic, everything else in React — forms, effects, context — is just variations on that loop.