React exposes useInsertionEffect alongside useEffect and useLayoutEffect. When does it fire relative to the other two, who is it intended for, and what can you not do inside it?

## The problem it exists to solve A runtime CSS-in-JS library generates class names during render and must get the matching rules into the document. If it inserts them too late, two things go wrong. Layout effects that measure elements do so before the styles apply, so every measurement is taken against the wrong box. And inserting rules while the browser is in the middle of laying things out forces extra style recalculation on the critical path. `useInsertionEffect` gives those libraries a slot that is early enough: React runs insertion effects **before any layout effects** in the commit. By the time a layout effect runs and reads the DOM, the rules that library injected are already in the document. ```js // inside a CSS-in-JS library, not in product code useInsertionEffect(() => { if (!isInserted(rule)) insertStyleRule(rule); }); ``` ## Ordering, stated carefully The fact worth memorising is the relative one: insertion effects run before layout effects, and layout effects run before the browser paints, and passive effects (`useEffect`) run after. What React deliberately does **not** promise is that the DOM has already been updated when an insertion effect runs — the documentation says it may run either before or after the DOM mutation, so you must not write code inside it that depends on the committed DOM being in place. That is a restriction, not an implementation detail to work around; it is what keeps React free to schedule the slot as it needs to. ## What React forbids inside it The hook is deliberately narrow: - **Refs are not attached yet.** Anything you would reach for a DOM node with is unavailable, which is another reason it is the wrong tool for measurement. - **You cannot update state.** Calling a setter from an insertion effect is not supported; the slot exists to write into the document, not to drive a re-render. - **It does not run on the server.** Like every effect, it belongs to the commit, and a server render never commits — so a library still needs a separate path for collecting styles during server rendering. Those limits fall straight out of *when* it runs: too early for refs, too early to be a place where React re-enters rendering. ## Why product code should not use it Interviewers ask about this hook to see whether you can place a rarely used API correctly rather than to see you use it. The honest answer is that application components have no business calling it. If you need to run something before the user sees the frame, that is `useLayoutEffect`. If you need it after, that is `useEffect`. The only reason `useInsertionEffect` was added is that style injection has a hard ordering requirement relative to layout reads that neither of the other two could satisfy, and only a library that owns style injection has that requirement. A good answer therefore has three parts: it fires before layout effects; it exists so injected styles are present before anything measures; and its restrictions (no refs, no state updates, no server run, no guaranteed DOM) mark it as library-only. If you cannot recall the restrictions, say confidently that it is a CSS-in-JS hook that runs earlier than `useLayoutEffect` and that you would not put it in application code — that is a stronger answer than inventing capabilities it does not have.