React Events: onClick, onChange, onSubmit and More

React handles events with props named after the event in camelCase, such as onClick, onChange and onSubmit. You pass a function, and React calls it with an event object when the user clicks, types or submits.

import { useState } from 'react';

export default function App() {
    const [likes, setLikes] = useState(0);

    function handleClick() {
        setLikes(likes + 1);
        console.log('Liked');
    }

    return <button onClick={handleClick}>Like ({likes})</button>;
}

Each click runs handleClick, which updates the count and logs to the console under the preview. Try onDoubleClick in place of onClick: now only a double click counts.

Pass the function, do not call it

The prop takes a function, and React calls it later. A very common mistake is adding parentheses, which calls the function right away, during render, and hands React its return value instead.

function sayHi(name) {
    console.log('Hi, ' + name);
}

export default function App() {
    return (
        <div>
            <button onClick={sayHi('during render')}>Wrong</button>{' '}
            <button onClick={() => sayHi('Ada')}>Right</button>
        </div>
    );
}

The console shows "Hi, during render" before you touch anything: React ran sayHi while rendering the first button, and since sayHi returns undefined, that button has no handler at all. Clicking Wrong does nothing. Clicking Right logs "Hi, Ada", because the arrow function only runs on click.

The arrow is also how you pass arguments. onClick={() => removeItem(item.id)} creates a small function for each item, and that function calls yours with the right ID. If a handler takes no arguments, pass it by name: onClick={handleClick}.

With a state setter the mistake is worse: onClick={setCount(count + 1)} sets state during render, which renders again, which sets state again, and React stops with "Too many re-renders".

The event object

React passes every handler one argument, the event object. It has the same properties as the browser's event: e.target is the element the event happened on, e.key is the key that was pressed, e.preventDefault() cancels the browser's default action. React wraps the native event in what it calls a synthetic event, so it behaves the same in every browser; the original is at e.nativeEvent if you ever need it.

The two you use most are e.target.value in onChange and e.key in onKeyDown.

import { useState } from 'react';

export default function App() {
    const [text, setText] = useState('');
    const [tags, setTags] = useState(['react']);

    function handleKeyDown(e) {
        console.log('key:', e.key);
        if (e.key === 'Enter' && text.trim() !== '') {
            setTags([...tags, text.trim()]);
            setText('');
        }
        if (e.key === 'Escape') {
            setText('');
        }
    }

    return (
        <div>
            <input
                value={text}
                onChange={(e) => setText(e.target.value)}
                onKeyDown={handleKeyDown}
                placeholder="Type a tag, press Enter"
            />
            <p>Tags: {tags.join(', ')}</p>
        </div>
    );
}

Type hooks and press Enter: the tag is added and the field clears. The console logs every key, including Shift, Backspace and Enter, by the names in e.key. Press Escape halfway through a word to throw it away.

React's onChange fires on every keystroke. In plain HTML the change event on a text field fires only when it loses focus, so this is a deliberate difference: it lets the input and state stay in step letter by letter. Checkboxes give you e.target.checked instead of value. The forms page covers every input type.

Forms and preventDefault

When a form is submitted, the browser's default action is to send it and load a new page. In a React app you almost always want to handle the data yourself, so the submit handler starts with e.preventDefault().

import { useState } from 'react';

export default function App() {
    const [email, setEmail] = useState('');
    const [sent, setSent] = useState(null);

    function handleSubmit(e) {
        e.preventDefault();
        console.log('Subscribing', email);
        setSent(email);
        setEmail('');
    }

    return (
        <form onSubmit={handleSubmit}>
            <input
                name="email"
                type="email"
                required
                value={email}
                onChange={(e) => setEmail(e.target.value)}
                placeholder="you@example.com"
            />{' '}
            <button type="submit">Subscribe</button>
            {sent && <p>Thanks, {sent} is on the list.</p>}
        </form>
    );
}

Put onSubmit on the <form>, not onClick on the button: then pressing Enter in the field submits too, and the browser's own checks (here required and type="email") run first. Delete the e.preventDefault() line and submit again: a real page would now leave for a new page and lose the thanks message. The preview blocks that and shows what the form would send instead, email= with no value, because setEmail('') had already cleared the field when the form was read.

React 19 also lets you pass a function to <form action={fn}>, which receives the form data and resets uncontrolled fields for you. The forms page shows both styles.

Bubbling and stopPropagation

Most events bubble: after running on the element you clicked, they run on its parent, then on the parent's parent, up to the top. React handlers follow the same order. That is why a click on a button inside a clickable card also counts as a click on the card.

const box = { padding: 12, border: '1px solid #bbb', borderRadius: 6, marginTop: 8 };

export default function App() {
    return (
        <div style={box} onClick={() => console.log('3. outer card')}>
            Outer card
            <div style={box} onClick={() => console.log('2. inner panel')}>
                Inner panel
                <div style={{ marginTop: 8 }}>
                    <button onClick={() => console.log('1. button')}>Bubbles up</button>{' '}
                    <button
                        onClick={(e) => {
                            e.stopPropagation();
                            console.log('1. button that stops here');
                        }}
                    >
                        Stops here
                    </button>
                </div>
            </div>
        </div>
    );
}

Click Bubbles up and the console logs the button, then the inner panel, then the outer card. Click Stops here and only the button logs: e.stopPropagation() ends the climb. Clicking the inner panel's own text logs the panel and the card.

Use stopPropagation sparingly. A common legitimate case is a delete button inside a clickable list row, where clicking delete should not also open the row. If a parent needs to know whether the click came from a child, check e.target instead of stopping the event. To run a handler on the way down instead, before children see the event, React offers capture versions such as onClickCapture.

preventDefault and stopPropagation are different tools. The first cancels what the browser would do (follow a link, submit a form, tick a checkbox). The second stops other handlers from hearing about the event. Calling one does not do the other.

Other common events

The same pattern covers every event React supports. A few you will use often:

• onFocus and onBlur fire when an input gains and loses focus, handy for showing validation after the user leaves a field.
• onMouseEnter and onMouseLeave fire when the pointer moves onto and off an element. Unlike most events they do not bubble, so moving the pointer from a parent into its child does not fire the parent's onMouseEnter again.
• onPointerDown, onPointerMove and onPointerUp work for mouse, touch and pen alike, which makes them the better choice for dragging.
• onScroll fires as an element scrolls. In React it does not bubble.

Each handler receives an event object with the properties that make sense for it: e.clientX for pointer events, e.key for keyboard events, e.target for all of them.

Passing handlers as props

Components can accept handlers from their parent like any other prop. Name them onSomething after what happened, and name the function that handles it handleSomething. This mirrors the built-in events and makes it obvious which props are callbacks.

import { useState } from 'react';

function Stepper({ value, onIncrement, onDecrement }) {
    return (
        <span>
            <button onClick={onDecrement}>-</button>
            <b style={{ margin: '0 8px' }}>{value}</b>
            <button onClick={onIncrement}>+</button>
        </span>
    );
}

export default function App() {
    const [qty, setQty] = useState(1);

    function handleIncrement() {
        setQty(qty + 1);
    }
    function handleDecrement() {
        setQty(Math.max(0, qty - 1));
    }

    return (
        <p>
            Quantity: <Stepper value={qty} onIncrement={handleIncrement} onDecrement={handleDecrement} />
        </p>
    );
}

Stepper does not own the number; it reports clicks and the parent decides what they mean. Change handleDecrement to stop at 1 instead of 0 and the stepper follows without being edited. Keeping state in the parent and passing handlers down is the pattern described in lifting state up.

Custom handler props are only names. onIncrement on your own component does nothing until the component passes it to a real element's onClick, and you can give it any arguments you like, for example onSelect(item.id).