The React Compiler only produces correct output for code that follows the Rules of React. Which properties does it rely on, and what happens when a component breaks them?

## Why purity is the precondition Memoization is a bet: if the inputs did not change, the output cannot have changed, so it is safe to reuse the previous result. That bet is only valid when the function is *pure* — its result depends solely on its inputs, and running it has no effect anyone else can observe. Hand-written `useMemo` makes the same bet, but a human makes it one call site at a time and can eyeball the code. The React Compiler makes it everywhere, automatically. So the properties that were previously "good practice" become the compiler's correctness contract. ## The properties it relies on **Render is pure.** Given the same props, state and context, a component returns the same JSX. No random values, no reading a clock or a global mutable counter to decide what to show. **No mutation during render.** A component must not mutate its props, its state, values from context, or any object it already returned in JSX. Creating and mutating a *local* object before returning it is fine — the object is not observable elsewhere yet. The rule is about mutating things that already have another owner. **No side effects during render.** No writing to refs, no subscribing, no calling a setter of another component, no touching the DOM. Those belong in event handlers or effects. **Hooks are called unconditionally, at the top level of a component or another hook.** The compiler needs a fixed, statically known shape for the function to place its cache slots. This is the Rules of Hooks constraint that was always there; the compiler simply cannot work around a violation. ## Two very different failure modes **Detected violation: the compiler bails out.** The compiler is conservative. When its analysis cannot prove a function is safe to memoize — a conditional hook call, a mutation pattern it recognises, a construct it does not model — it skips that function and emits it unchanged. Your app still works; that component is simply not optimised. This is the common case, and it is why enabling the compiler on a messy codebase is usually uneventful rather than catastrophic: you get less benefit, not broken behaviour. **Undetected violation: stale UI.** The genuinely bad case is a violation static analysis cannot see. The classic shape: ```jsx function Chart({ config }) { config.points = compute(config.raw); // mutating a prop during render return <Canvas points={config.points} />; } ``` The compiler sees `config` unchanged by reference on the next render and reuses the cached `<Canvas />`, but the real content depends on a mutation it did not model. The screen shows last render's data. The same shape appears with a module-level object mutated during render, or an array from context sorted in place. These bugs are hard to attribute because the *compiler* looks like the culprit while the mutation is the actual defect — the uncompiled build merely hid it by re-running everything every time. ## Finding violations before the build depends on them Run the compiler's lint rule and treat its findings as blocking. `eslint-plugin-react-compiler` runs the same analysis the compiler runs and reports it in the editor, so a mutation-during-render or a conditional hook call shows up while you are writing it rather than as a stale pixel two sprints later. Fixing what it reports has a second payoff: every violation you clear is a component that moves from "skipped" to "compiled", so the lint burn-down is also the optimisation burn-down. When you are diagnosing a suspected miscompilation, the escape hatch is the `"use no memo"` directive on the one function, used to bisect. If opting a component out fixes the bug, you have localised it — and the next step is finding the impurity in that component, not leaving the directive there forever. ## What an interviewer is listening for The weak answer is "the compiler needs clean code". The strong answer names the specific property (purity, no mutation of things you do not own during render), distinguishes the conservative bail-out from the silent staleness, and says that the lint rule is the mechanism that turns a convention into an enforced precondition. Bonus points for the observation that these bugs pre-existed the compiler — an impure render was always a latent bug; auto-memoization only stops paying to hide it.