Passing Arguments to Event Handlers

The plain-language idea

An event handler like onClick={handleClick} takes no arguments beyond the event React gives it for free. The moment you need to pass your own argument — which item was clicked, which row, which id — you need one more level of function. There are two common ways to get there: wrap it in an inline arrow, or write a function that takes your argument and returns a handler.

// Inline arrow — most common, most readable at the call site
<button onClick={() => deleteItem(item.id)}>Delete</button>

// Curried handler factory — a function that returns a function
function makeDeleteHandler(id) {
  return () => deleteItem(id);
}
<button onClick={makeDeleteHandler(item.id)}>Delete</button>

Both do the same thing: produce a new function, scoped to this specific item.id, that React calls with no arguments of its own when the click fires. The inline arrow is shorter and keeps the argument visible right next to the JSX that uses it. The factory pulls the function-creation logic out of the render, which can help when the handler itself is nontrivial enough that inlining it clutters the markup.

See it in a real thing: a list of rows

function TodoList({ todos, onToggle }) {
  return (
    <ul>
      {todos.map((todo) => (
        <li key={todo.id}>
          <input
            type="checkbox"
            checked={todo.done}
            onChange={() => onToggle(todo.id)}
          />
          {todo.label}
        </li>
      ))}
    </ul>
  );
}

Every render of this list creates a brand-new arrow function for every <input> — todos.length new functions, every time. That sounds expensive stated like that. In practice it almost never is: creating a function is one of the cheapest operations a JS engine does, and unless a handler is doing real, measurable work in React.memo's comparison (see this track's re-render lesson for the actual list of what forces a re-render in the first place), a fresh function reference per render is not what's making anything slow.

What people usually miss

Watch out

• "New function every render" is not automatically a performance problem. It only matters when something is comparing that function by reference (memoization, an effect dependency) — most onClick handlers on plain DOM elements like <button> or <input> are never compared to anything, so a fresh closure each render costs nothing observable.
• The curried factory doesn't avoid creating a new function either. makeDeleteHandler(item.id) still allocates a new closure on every call, same as the inline arrow — the factory changes where the function is written, not whether a new one gets created.
• Readability, not performance, is the honest reason to prefer one style over the other. Pick inline arrows for simple, one-line handlers where the argument is obvious in context; pull out a named factory function when the handler logic is long enough that inlining it would bury the JSX.

The genealogy: this is what causes a re-render, applied

This track's lesson on what actually forces a component to re-render draws a hard line between "a new value was created" and "something re-rendered because of it" — a prop changing only matters if a parent re-renders and something downstream is specifically comparing that prop by reference. Creating a new event-handler function on every render is a concrete instance of exactly that line: harmless by default, and only worth optimizing once something is actually comparing the function itself.