A React 19 component attaches its own click listener to a child DOM node with addEventListener via a ref, and the same subtree also has React onClick and onClickCapture props. In what order do these run, and what happens when either side calls stopPropagation?

## Reason from position, not from framework folklore There is no special rule for "React handlers versus native handlers". There is one rule: the browser propagates the event through the real DOM, capture phase downward then bubble phase upward, and every listener runs when the event reaches *its* node. React's listeners are just listeners — they happen to be on the root container, and everything they do afterwards is dispatch, not propagation. So draw the tree: ``` document └── #root <- React's capture + bubble listeners live here └── <div> <- your addEventListener via a ref └── <button> <- event.target ``` ## The resulting order For a click on the button: 1. **Capture, downward.** `document` capture listeners, then `#root` — React's capture listener fires here and immediately dispatches every `onClickCapture` prop it collects along the React tree, outermost-first. Then the browser continues down and your native *capture* listener on the `<div>` fires. 2. **Bubble, upward.** Your native *bubble* listener on the `<div>` fires. Then the event reaches `#root`, React's bubble listener fires, and React dispatches every `onClick` prop along the React tree, innermost-first. Then `document`. Two consequences people find counterintuitive: - **All** React capture handlers — including one on a deeply nested component — run *before* a native capture listener on a node above that component, because React replays the whole capture pass at the container in one go. - A native bubble listener on the immediate parent `<div>` runs *before* the `onClick` on the `<button>` itself, even though the button is the deeper node. React's bubble pass has not started yet. ```javascript import { useEffect, useRef } from 'react'; function Row() { const ref = useRef(null); useEffect(() => { const el = ref.current; const onNative = () => console.log('2. native bubble on the div'); el.addEventListener('click', onNative); return () => el.removeEventListener('click', onNative); }, []); return ( <div ref={ref} onClickCapture={() => console.log('1. onClickCapture')}> <button onClick={() => console.log('3. onClick')}>go</button> </div> ); } ``` ## stopPropagation across the boundary **Native listener stops it (below the root container).** The event never reaches the container, React's listener never fires, and *nothing* is dispatched — not the handler on that subtree, not `onClick` on ancestors, not capture handlers if the stop happened during capture. From inside React it looks as if the framework broke. This is the first thing to check when a click handler mysteriously does nothing in an app that also contains third-party DOM code, a drag library, or a `stopPropagation()` someone added to "contain" a click. **React handler stops it.** Calling `stopPropagation()` on the synthetic event stops the underlying propagation from continuing past the root container, so listeners on `document` or `window` do not run. But your native listener on the inner `<div>` already ran — it fired before React was ever involved. You cannot retroactively cancel it. The practical version: a dropdown that closes on outside clicks via `document.addEventListener('click', close)` stops closing the moment someone adds `stopPropagation()` to a React `onClick` inside the menu, because that document listener is above the root container. Detect outside clicks with a containment check (`ref.current.contains(event.target)`) or a capture-phase listener rather than relying on propagation reaching `document`. ## Ordering among listeners on the same node If you attach a native listener to the root container itself, ordering against React's listener on that node is decided by registration order within the phase — which depends on when your code ran relative to root creation. That is fragile by construction; do not build behaviour on it. ## What to actually do - **Pick one side per subtree.** Handling the same event both natively and through props in the same region is the failure mode; the ordering rules are learnable but nobody re-derives them during a bug hunt. - **When you must go native** — because a third-party widget owns the node, or you need a non-passive listener for `preventDefault` on a scroll-blocking touch event — attach on the specific node, document the ordering you rely on, and clean up in the effect's teardown. - **Prefer containment checks over propagation tricks.** `element.contains(event.target)` does not care which side of the boundary handled the event first. - **Be suspicious of every stopPropagation in a React codebase.** It is a global claim about a subtree made from one component, and it is exactly what breaks native listeners above and below. ## Saying it in an interview "React's listeners are on the root container, so during capture React runs first and during bubbling it runs last. A native bubble listener on a child therefore beats `onClick`, and if it stops propagation React never dispatches at all. React's own `stopPropagation` stops listeners above the root — `document`, `window` — but not ones that already fired inside."