A React dashboard stores the cursor position in state on the page component so a tooltip can follow the mouse, and every mousemove re-renders a heavy chart and table. Without memoizing the chart or the table, how would you restructure the components so only the tooltip updates?

## Why the whole dashboard repaints The rule that decides everything here: a state update re-renders the component that owns the state, and then the components it renders, until React can bail out. Cursor coordinates in the page component mean the page is the owner, and the chart and table are in its subtree. Pointer moves fire at roughly display refresh rate, so the app is asking React to walk the whole dashboard tens of times a second for a two-number change. Notice what is *not* the problem: the event system, batching, or the chart itself. React batches these updates fine and the chart renders at a perfectly normal speed — just far too often. The defect is structural. ## Step 1 — give the fast state the smallest owner you can Move both the listener and the state into a dedicated component whose entire output is the tooltip. ```jsx function MouseTooltip({ label }) { const [pos, setPos] = useState(null); useEffect(() => { const onMove = e => setPos({ x: e.clientX, y: e.clientY }); window.addEventListener('mousemove', onMove); return () => window.removeEventListener('mousemove', onMove); }, []); if (!pos) return null; return <div style={{ position: 'fixed', left: pos.x, top: pos.y }}>{label}</div>; } ``` Rendered as a sibling of the chart, this component's updates cannot reach the chart: the chart is not in its subtree. That single move usually ends the problem, and it costs no cache, no comparator and no dependency array. ## Step 2 — if it must wrap, relay the content Sometimes the tooltip owner also has to be the positioned container, so the dashboard has to live inside it. Then keep the state where it is but stop *authoring* the dashboard there: ```jsx <TooltipLayer label="details"> <Chart data={data} /> <ResultsTable rows={rows} /> </TooltipLayer> ``` `TooltipLayer` owns the coordinates and renders `{children}`. Because those elements are created in a parent that is not re-rendering, `props.children` is the identical object on every mousemove update, and React bails out on the whole relayed subtree. The state stayed high; the *authorship* of the expensive tree moved up. That is the same lever as moving state down, applied from the other side. ## Step 3 — for true per-frame visuals, leave React out Coordinates that change every frame and only move pixels do not need to be state at all. Keep a ref to the tooltip node and write the position directly in the listener: ```jsx const nodeRef = useRef(null); useEffect(() => { const onMove = e => { const node = nodeRef.current; if (node) node.style.transform = `translate(${e.clientX}px, ${e.clientY}px)`; }; window.addEventListener('mousemove', onMove); return () => window.removeEventListener('mousemove', onMove); }, []); ``` No render, no reconciliation — just a style write. Use this deliberately and sparingly: the value is now invisible to React, so nothing else may derive from it, and it must not affect anything semantic or accessible. Drag handles, cursor followers and scroll-linked ornamentation are the honest use cases. ## The answers that sound plausible and are worse - **Throttle the state update.** Fewer oversized renders is still oversized renders, and the tooltip now visibly lags the cursor. Frequency is the symptom; scope is the disease. - **Wrap the chart and table in `React.memo`.** It works until someone passes an inline object or a fresh callback, then it silently stops, and every prop of both components becomes something reviewers must keep stable forever. - **Put the coordinates in a context provider at the page root.** Strictly worse: now every consumer under the provider re-renders on each mousemove, and the value is a new object every time. ## Verifying the fix Record a profile while moving the mouse and look at what appears in each commit. Success is a commit list containing the tooltip and nothing else; if the chart is still in there, the state has not actually left its subtree — usually because a coordinate is still being read one level too high, or the parent re-renders for its own reasons and re-creates the relayed elements.