Class Lifecycle and Hook Equivalents

## The mapping candidates memorize Every migration guide prints roughly the same table: | Class method | Hook shape | | --- | --- | | componentDidMount | `useEffect(() => { ... }, [])` | | componentDidUpdate | `useEffect(() => { ... }, [dep])` | | componentWillUnmount | the function returned from the effect | It is close enough to pass a screening question, and it is exactly why so much migrated code is subtly wrong. ## The same component both ways A class that keeps a connection in sync with a `roomId` prop needs three methods, and the update path duplicates the other two: ```jsx class Chat extends React.Component { componentDidMount() { this.conn = connect(this.props.roomId); } componentDidUpdate(prevProps) { if (prevProps.roomId !== this.props.roomId) { this.conn.close(); this.conn = connect(this.props.roomId); } } componentWillUnmount() { this.conn.close(); } render() { return <h1>{this.props.roomId}</h1>; } } ``` The function version says the same thing once: ```jsx function Chat({ roomId }) { useEffect(() => { const conn = connect(roomId); return () => conn.close(); }, [roomId]); return <h1>{roomId}</h1>; } ``` The class version is a sequence of moments — mounted, updated, about to be destroyed. The hook version is a rule — for this `roomId`, this connection should exist; when the value changes, tear the old one down and set the new one up. Nothing in the hook version mentions mounting. ## Where the mapping breaks **Cleanup is not unmount code.** React runs the cleanup returned by the previous run before every re-run, and once more when the component is removed. Code written as "componentWillUnmount, therefore this only happens once, at the end" leaks or double-registers as soon as a dependency changes. In the class, that teardown-then-setup pairing had to be hand-written inside componentDidUpdate, and forgetting it was the classic class-era subscription leak. **There is no prevProps.** The class compared previous and current values itself. In a function component the dependency array is that comparison: React stores the previous array and compares each entry with `Object.is`. You do not get the old value handed to you, and reintroducing it with a ref that stores the last props is a sign you are still thinking in lifecycles. **There is no "skip the first render".** componentDidUpdate ran only on updates. An effect always runs after the first commit, so a literal port of update-only logic fires once too often. People bolt on a `useRef(true)` first-render flag; usually the real fix is that the code was never an effect at all — it was a response to a user interaction and belongs in the event handler. **The timing is different.** componentDidMount and componentDidUpdate run synchronously after React commits to the DOM and before the browser paints. `useEffect` is deferred until after paint. The hook whose timing actually matches the class methods is `useLayoutEffect`. For most work the difference is invisible; for reading layout and adjusting it, the difference is a visible flicker. **Instance fields versus closures.** `this.conn` is one slot that survives every render. A function body re-runs from scratch each render, and each effect closes over the props and state of the render that created it. That is a feature — each run sees a consistent snapshot — but it is a different model from mutating `this`, and code that assumed a single long-lived instance has to move that value into a ref deliberately. ## How to answer it Give the table, then immediately say why it is a teaching crutch: one effect replaces three methods because an effect is not a lifecycle callback but a synchronization rule, and the dependency array is the comparison the class did by hand. The two concrete consequences worth naming are that cleanup runs on every re-run rather than only at unmount, and that effects run after paint while componentDidMount ran before it.