React Events: Pass, Don't Call

React handles user actions with event handler functions passed as props, like onClick={handleClick}. This is how you make buttons or forms interactive. The key mistake is calling the function (onClick={doIt()}), which runs on render, not on click.
Why it exists
React needed a declarative way to handle user interactions that fits its component model. Instead of manually finding DOM nodes and attaching event listeners, React lets you specify the response function directly in your JSX, keeping the logic and view tightly coupled within the component.
The mental model
Think of an event handler as a callback you hand to React. You're not running the function yourself. You're saying, "Hey React, when a user clicks this button, please run this specific function for me." You pass the function reference, and React calls it at the right time.
How it works
You make an element interactive by passing a function to a special prop like onClick, onMouseEnter, or onChange. These props correspond to standard DOM events. For example, you define a function handleClick inside your component and pass it by name: <button onClick={handleClick}>.
The most critical error is calling the function instead of passing it. Correct is <button onClick={handleClick}>, which passes the function reference. Incorrect is <button onClick={handleClick()}>, which calls the function on render. The parentheses () execute the function immediately during the component's render phase. If this function updates state, you'll create an infinite loop. The code runs every time the component draws, not when the user clicks. The same applies to inline handlers: onClick={() => alert('hi')} is correct because it passes a function, while onClick={alert('hi')} is wrong because it calls alert on render.
When to use it
This is the standard, idiomatic way to handle any user-driven event in React. Use it for clicks, form submissions, keyboard inputs, and mouse movements. Because handlers are defined inside the component, they can easily access props and state to perform dynamic actions.
When not to use it
This pattern is the default for almost all event handling. The main alternative, manually adding DOM listeners with useEffect and refs, is considered an "escape hatch." Only resort to it for complex interoperability with non-React libraries or for performance optimizations on high-frequency events where you need fine-grained control.
One canonical example
function Toolbar() {
const handlePlayClick = () => alert('Playing movie!');
const handleUploadClick = () => alert('Uploading image!');
return (<button onClick={handlePlayClick}>Play Movie</button> <button onClick={handleUploadClick}>Upload Image</button> ); } Here, two distinct handler functions are defined and passed by reference to the onClick prop of their respective buttons. React invokes the correct function only when the corresponding button is clicked.
Interview question
What is the primary issue with using `onClick={myFunction()}` instead of `onClick={myFunction}` in a React component?
- a.It prevents React from optimizing event listener attachment, leading to performance degradation.
- b.React's event system cannot correctly pass the event object to `myFunction` when called this way.
- c.It executes `myFunction` immediately during the component's render phase, not when the user clicks.Correct
- d.It causes a syntax error in JSX, preventing the component from rendering.
Why? this is the answer
The card explicitly states that `onClick={handleClick()}` is incorrect because "The parentheses () execute the function immediately during the component's render phase." This means the function runs when the component is drawn, not when the user interacts with it. Option D is incorrect because it's a logical error, not a syntax error.
Just read this? Test yourself on what you have been reading.
Read the original → react.dev
- #react
- #javascript
- #ui
- #events
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on react — each one lists the topics its interview covers.
See open roles