A React component that calls useLayoutEffect produces a warning during server rendering saying the hook does nothing on the server. Why does React warn about this, and what are your options for dealing with it?

## What server rendering actually does A server render is a single pass. React walks the component tree, calls each function component, and turns the result into HTML — with `renderToString`, or streamed with `renderToPipeableStream`. There is no DOM, no commit phase, no browser, and therefore no paint. Effects are part of the commit, so none of them run: not `useEffect`, not `useLayoutEffect`. Only the render-phase code executes. That is not a limitation React could remove. There is nothing on the server for a layout effect to measure or mutate, and no frame for it to get ahead of. ## Why only one of the two hooks warns If effects never run on the server, why does React single out `useLayoutEffect`? Because of what each hook *promises*. `useEffect` says "run this after the update is visible" — on the server there is no update to be visible, so skipping it is harmless and no warning is issued. `useLayoutEffect` says "run this **before** the user can see the result". A component that uses it is asserting that the DOM as first rendered is wrong and must be corrected before anyone sees it. On the server that assertion cannot be satisfied at all: the HTML the user receives is the uncorrected version. The practical consequence is a real, visible defect. The browser paints the server HTML as soon as it arrives, showing the un-corrected layout. Only when the JavaScript loads and hydration commits does the layout effect finally run and fix things. The user sees the wrong state not for one frame but for however long hydration takes — the exact flash `useLayoutEffect` was chosen to eliminate, made worse. The warning is React telling you that the guarantee you asked for is unavailable on this path. ## The three honest responses **1. It did not need to be a layout effect.** This is the most common case. The work does not actually change what is on screen for the current frame — it starts a timer, records something, syncs with an external system — and someone reached for `useLayoutEffect` because timing felt flaky. Move it to `useEffect` and the warning and the problem both disappear. **2. Do not render the correction-dependent UI on the server.** Restructure so the first pass renders something that is correct without any adjustment, and apply the adjustment after mount. In practice that means the server and the first client render agree on markup, an effect flips a flag, and the corrected version renders on the second pass: ```js const [mounted, setMounted] = useState(false); useEffect(() => setMounted(true), []); // render the plain version until mounted, the adjusted one after ``` This is the honest fix when the adjustment truly depends on the browser, because it accepts that the server cannot know the answer instead of pretending otherwise. Two-pass rendering costs an extra client render and delays the corrected view slightly, so it is worth it only for the part of the tree that genuinely needs it. **3. The isomorphic-layout-effect idiom.** Libraries that must keep pre-paint behaviour on the client, and that render on the server only incidentally, pick the hook by environment: ```js const useIsomorphicLayoutEffect = typeof window !== 'undefined' ? useLayoutEffect : useEffect; ``` Both hooks have identical signatures, so this is a drop-in swap. Be clear about what it buys: it **silences the warning**. It does not make anything run on the server, and it does not remove the post-hydration correction. It is appropriate when the component's server output is acceptable as-is and the warning is pure noise; it is a cover-up when the server HTML is genuinely wrong, and reaching for it reflexively is the mistake an interviewer is probing for. ## How to talk about it Start from the mechanism — one render pass, no DOM, no commit, so no effects — then explain why the warning targets the pre-paint promise specifically, then give the decision: demote to `useEffect`, restructure so the first pass needs no correction, or knowingly silence it. Saying "just wrap it in a typeof window check" without the reasoning is the weak answer, because it treats a warning about a user-visible defect as a lint annoyance.