In React 19, what object does React pass to an event handler such as onClick, and how do you reach the underlying browser event from it?

## What React actually hands you When you write `<button onClick={handleClick}>`, React does not hand `handleClick` the object the browser created. It hands you a **SyntheticEvent** — a React-created wrapper object that holds a reference to the browser's event and re-exposes its interface. ```js function handleClick(e) { console.log(e.type); // 'click' console.log(e.target); // the DOM node that was clicked console.log(e.currentTarget); // the node this handler is attached to in the React tree console.log(e.nativeEvent); // the browser's MouseEvent } ``` The wrapper is not a stripped-down object. It implements the same members the W3C event model defines: `bubbles`, `cancelable`, `currentTarget`, `defaultPrevented`, `eventPhase`, `isTrusted`, `target`, `timeStamp`, `type`, plus `preventDefault()` and `stopPropagation()`. Type-specific events add their own normalized properties — a mouse event carries `clientX`, `clientY`, `button`, `shiftKey`, `metaKey`; a keyboard event carries `key`, `code`, `repeat`, `getModifierState()`. ## Two things React adds Beyond the DOM surface, React adds `isDefaultPrevented()` and `isPropagationStopped()`. These are React's own predicates: a downstream handler can ask whether an earlier handler already cancelled the event, which is useful when several components cooperate on the same interaction. ## Why a wrapper at all Historically the answer was purely cross-browser normalization — old browsers disagreed about property names, about whether an event bubbled, and about how you cancelled it. Modern browsers agree on most of that, but the wrapper still earns its place for two reasons. First, React *synthesizes* events that do not map one-to-one onto native ones. React's `onChange` on a text input fires on every keystroke; the native `change` event fires only when the field is committed. React implements `onChange` on top of the native `input` event so that controlled inputs have a single sensible hook. Likewise `onFocus` and `onBlur` bubble in React, because React backs them with the bubbling `focusin`/`focusout` events rather than the non-bubbling `focus`/`blur`. Second, a uniform object gives React a place to hang its own semantics — the predicates above, and a consistent notion of `currentTarget` expressed in terms of the *React* tree rather than raw DOM ancestry. ## The escape hatch: e.nativeEvent Normalization means React exposes a curated subset. When you need something outside that subset, `e.nativeEvent` gives you the real browser object, untouched: ```js function handleSubmit(e) { e.preventDefault(); const button = e.nativeEvent.submitter; // which button submitted the form } ``` This is a supported, documented property — not a private field. Reaching for it is normal; you just accept that whatever you read there is browser behaviour, not React behaviour, so it is on you to check support. ## What is no longer true Many older answers add "but the event is pooled, so copy what you need before it is recycled." That was accurate up to React 16. React 17 removed pooling entirely, and React 19 keeps it removed. The synthetic event is an ordinary object with an ordinary lifetime: you can stash it in a variable, put it in a closure, or read it after awaiting a request. `e.persist()` is still callable so old code does not break, but it does nothing. One caveat survives, and it is a DOM rule rather than a React rule: `e.currentTarget` is only meaningful while the event is being dispatched. Once dispatch finishes, the browser resets it, so reading `e.currentTarget` after an `await` gives `null` — for native events too. Read it synchronously and keep the value if you need it later. ## What to say in an interview Name the object, say it mirrors the DOM event interface with cross-browser normalization, name `e.nativeEvent` as the escape hatch, and mention that pooling is gone. That covers everything an interviewer is checking for.