Write a React `useOnClickOutside(ref, handler)` hook that closes a dropdown when the user clicks elsewhere. Which document event should it listen for, and how do you stop a new inline `handler` from tearing down and re-attaching the listener on every render?

## The hook ```js import { useEffect, useRef } from 'react'; function useOnClickOutside(ref, handler) { const handlerRef = useRef(handler); useEffect(() => { handlerRef.current = handler; }); useEffect(() => { const listener = event => { const el = ref.current; if (!el || el.contains(event.target)) return; handlerRef.current(event); }; document.addEventListener('pointerdown', listener); return () => document.removeEventListener('pointerdown', listener); }, [ref]); } ``` ## Which event, and why it matters `click` fires after the pointer is released, which produces two real bugs. First, the menu stays open for the whole press, which feels laggy on touch. Second, if the user presses inside the menu and releases outside — a drag, or a text selection that runs past the edge — the click target is the common ancestor and the menu closes when it should not. `pointerdown` fires at press time, is a single event covering mouse, touch and pen, and matches how native menus behave. The trade-off worth naming out loud: closing on pointerdown means an outside button's own click may land on a page that has already re-laid-out, because the menu closed between the press and the release. Whether that matters depends on the layout; if elements shift, closing on `pointerup` or `click` is the deliberate alternative. An interviewer is listening for the awareness, not a fixed answer. A complete implementation also handles `keydown` for `Escape`, since a menu that closes only on an outside click is not keyboard-operable. ## The re-attachment problem Callers write `useOnClickOutside(ref, () => setOpen(false))`. That arrow is a new function object on every render. If the subscribing effect lists `handler` in its dependencies, React runs cleanup and setup on every single render: remove the listener, add it again, forever. It is not *incorrect* — the behaviour is right — but it is pure churn, and it makes the hook's cost proportional to how often its owner renders. The alternatives are worth ranking. Pushing the problem to the caller ("wrap your handler in `useCallback`") makes a shared hook unpleasant to use and one forgotten memo re-introduces the churn silently. Omitting `handler` from the dependency array while still closing over it is worse: the listener then permanently captures the first render's handler and reads stale state — the classic stale-closure bug, and one the exhaustive-deps lint rule will flag. The latest-ref pattern resolves both. A ref is a mutable box that does not participate in rendering, so refreshing `handlerRef.current` after each commit does not invalidate anything, and the listener resolves the function at *call* time rather than capturing it at *subscribe* time. The subscribe effect's only dependency is `ref`, which is itself stable for the component's lifetime, so the listener is attached exactly once. React has an in-progress `useEffectEvent` hook aimed at expressing precisely this "read the latest, do not depend on it" intent as a first-class API; until it is stable in the version you target, the ref is the portable spelling. ## Cleanup is not optional A `document`-level listener outlives the component unless removed. Every mount of a dropdown that forgets cleanup leaves a listener holding the component's closure — a leak that also produces phantom behaviour, since the stale listener still calls a handler for a menu that no longer exists. Returning the remover from the effect is the whole fix, and it is also what makes StrictMode's development-only double mount harmless: setup, cleanup, setup leaves exactly one listener. ## Where `contains` betrays you `Node.contains` asks about the DOM tree, not the React tree. Content rendered through a portal is a React child of your component but a DOM child of wherever the portal mounted — usually the document body. So a dropdown panel rendered into a portal is *not* contained by the trigger's ref, and clicking inside it closes the menu. The remedy is to check every relevant element: accept an array of refs, or have the panel itself register the ref the hook checks. A second trap is the element that opened the menu. If the trigger button is outside the ref, its own pointerdown counts as "outside", the handler closes the menu, and the button's click then reopens it — a menu that appears not to open at all. Either include the trigger in the checked elements or make the trigger toggle rather than open. ## Iframes and shadow DOM A click inside an `<iframe>` never dispatches an event in the parent document, so the menu stays open. Inside a shadow root, `event.target` is retargeted to the host element, so `contains` reports containment at host granularity; `event.composedPath()` is the API that gives the real path for composed events. These are the details that separate a hook that works in a demo from one that works in an application shell.