In React JSX, what is the difference between writing onClick={handleClick} and onClick={handleClick()}, and what actually happens with the second form?

## The prop wants a function, not a result A JSX attribute in braces is an ordinary JavaScript expression, evaluated at the moment the element is created — during render. React takes the resulting value and stores it as the element's prop. For an event prop such as `onClick`, React expects that value to be a function it can call later, when the user clicks. ```jsx <button onClick={handleClick}>Save</button> // reference: React calls it on click <button onClick={handleClick()}>Save</button> // call: the result becomes the prop ``` The two lines differ by two characters and by everything else. The first evaluates the identifier `handleClick` to a function object. The second evaluates a *call expression*: JavaScript runs `handleClick` right there and uses its return value. ## What the buggy form does Two symptoms follow, and a candidate should name both. **The button does nothing.** Most handlers return nothing, so the call evaluates to `undefined` and the element ends up with `onClick={undefined}` — the same as having no handler at all. Clicking produces silence, and there is no error to lead you to the cause. **The side effect fires at the wrong time.** Whatever the handler does — a network request, an analytics call, a state update — now happens while the component renders, and again on every subsequent render. Rendering is supposed to be a pure computation of what the UI should look like; performing effects there is exactly the thing React's model forbids. ## The infinite-render variant If the handler updates state, the two symptoms compound into a hard failure: ```jsx function Counter() { const [n, setN] = useState(0); // render -> setN -> re-render -> setN -> ... return <button onClick={setN(n + 1)}>{n}</button>; } ``` Render calls the setter, the state change schedules another render, that render calls the setter again. React detects the runaway loop and throws "Too many re-renders. React limits the number of renders to prevent an infinite loop." That message is a strong signal to look for a called-instead-of-passed handler, or for a state update sitting directly in the component body. ## When calling is correct The form is not always wrong. If the function is a *factory* whose return value is itself a function, calling it in the prop is exactly right: ```jsx const makeHandler = id => () => select(id); <button onClick={makeHandler(item.id)}>Pick</button> // prop is the inner function ``` Here the call happens during render, but it returns a handler, so the prop holds a function again. This is one of the two standard ways to pre-bind an argument. ## Passing arguments the usual way The reason people reach for the parenthesised form is almost always that they want to pass an argument. The idiomatic solutions are: - **An arrow wrapper:** `onClick={() => handleClick(id)}`. The prop is a function; the argument is captured by the closure. Costs one closure per render, which is normally irrelevant. - **A factory**, as above, when the same binding logic is reused. - **`Function.prototype.bind`:** `onClick={handleClick.bind(null, id)}`. Equivalent in effect and also allocates per render, but reads less clearly to most React developers than the arrow. All three keep a function in the prop. The distinction to internalise is: whatever the expression in the braces evaluates to is what React will try to call on the event. ## Spotting it TypeScript usually catches the mistake, because the event prop is typed to accept a function and you have supplied the call's result instead. In plain JavaScript there is no warning at all, so the tell is behavioural: a control that silently does nothing, an effect that runs on mount without you asking, or a "Too many re-renders" crash. When reviewing, read every event prop and ask whether the expression *is* a function or *produces* something else.