In a React function component that renders <input ref={inputRef} />, reading inputRef.current in the component body gives null, but reading it inside an effect gives the DOM element. What happens in between?

## The two moments Every update in React has a moment where it *decides* and a moment where it *applies*. **Deciding** is the render phase: React calls your component function. The function returns elements — plain objects describing what the UI should look like. Nothing has been created in the document at this point. Even on a re-render, React has not yet applied any change. Because there is no node, there is nothing to assign to a ref, so `inputRef.current` holds whatever you initialised it with. **Applying** is the commit phase. React walks the work it decided on and mutates the real DOM: creating elements, setting attributes, inserting and removing nodes. Ref attachment is part of that pass — once a node exists, React assigns it to the ref before it hands control back. Effects come after. Both `useLayoutEffect` and `useEffect` run once the commit has attached refs, which is the whole reason those hooks are where DOM work belongs. ```jsx const inputRef = useRef(null); console.log(inputRef.current); // null on the first render useEffect(() => { console.log(inputRef.current); // <input> }, []); return <input ref={inputRef} />; ``` ## Why React cannot just fill it in earlier The render phase is required to be pure: given the same props and state it should produce the same output and touch nothing outside itself. React relies on that so it can call a component more than once, discard the result of a render it no longer needs, or re-run work at a different priority. A DOM node is the definition of outside state. If refs were populated during render, every component would be tempted to read and write the document from a function React reserves the right to run speculatively — and the ref would have to point at *something*, even in a render whose output is never committed. ## Detachment matters too Attachment gets all the attention, but the reverse direction is what keeps refs safe. During the commit's mutation work, before or as a node is removed or replaced, React sets its ref back to `null`. That ordering is deliberate: it guarantees that at no point can you read `ref.current` and receive an element that has already been taken out of the document. When a node is replaced rather than removed, the same commit detaches the old ref and attaches the new one, so within a single update a ref never briefly points at the wrong element. This is why code that stashes `ref.current` in a variable and uses it later — inside a timer, a promise continuation, a debounced handler — is risky. The variable keeps a strong reference to a node that React has already detached and the browser may have discarded from the document. Reading `ref.current` at the moment you need it, and checking for `null`, is the habit to demonstrate. ## Second render, first render On the first render the ref is `null` because nothing exists yet. On subsequent renders the component body runs again *before* the new commit, so `ref.current` still holds the node from the previous commit. That is often harmless, but it is not "the current DOM": if this render is going to replace or remove the element, the value you read during the body is about to be stale. Treat the body as a place that has no valid view of the DOM at all, regardless of what it happens to contain. ## Where this shows up in real code The three classic cases are all commit-timing cases. Focusing an input on mount works from an effect and silently does nothing if attempted during render. Handing a node to an imperative library must happen after attachment, and the teardown must happen before detachment — which is exactly what an effect and its cleanup give you. And reading a size or position requires a node that is actually in the document, so it can only happen after the commit has put it there. ## The interview answer Keep it to the two phases: "the component body runs in the render phase, before React has created any DOM, so the ref is still `null`; React attaches refs while committing the result to the document, and effects run after that, so the ref is populated by the time your effect body executes." If you want to show a bit more, add the mirror image — React sets refs back to `null` while removing nodes, which is why a ref never points at a detached element.