Your team owns a React codebase with hundreds of class components. How would you decide whether and how to migrate them to function components with hooks?

## Frame it as investment, not repair The wrong opening is "classes are legacy, we should rewrite them". Class components render fine in React 19, and mixing them with function components requires no adapter — a class can render a function component and vice versa, and both see the same context and the same reconciliation. That means the migration can be arbitrarily incremental, which in turn means a big-bang rewrite is the one option with no justification. So the real question is what staying on classes costs, component by component. ## What classes actually cost **Capability.** Hooks are function-only. A class cannot call `use`, cannot use the Actions-era form primitives, and cannot consume any of the increasing number of libraries that ship hooks as their only API. When a class blocks a feature, that class has a business reason to move. **Automatic optimization.** The React Compiler inserts memoization at build time for function components that follow the Rules of React. Classes get none of it. For a component on a hot render path, that is a concrete, measurable difference, not a stylistic one. **Comprehension.** Lifecycle-shaped code splits one concern across three methods and merges unrelated concerns into one method. Effects group by concern instead. That is a real maintenance cost, but it is the softest of the three and should not be the headline argument. **Recruiting and review.** Newer engineers read hooks fluently and lifecycle code less so, which shows up as slower reviews and more subtle bugs in the class parts of the codebase. ## The policy I would set 1. **No new classes.** Enforce it in review. This alone stops the debt growing. 2. **Migrate on contact.** A component being modified for product reasons is converted in that change, while someone already has the behaviour paged in and there is a reason to test it. 3. **A short deliberate list.** Components that block a capability, sit on a measured hot path, or use the render-phase `UNSAFE_` lifecycles get scheduled explicitly with an owner. That list should be finite and visible. 4. **Leave the rest.** A stable component nobody has touched in two years is not costing anything; converting it spends review time and adds risk for no return. ## What stays a class Error boundaries still require a class — the boundary methods have no hook equivalent — so either keep a small hand-written boundary class or wrap the well-known library that provides one. This is a narrow, contained exception, and pretending otherwise in an interview is a tell. ## Budget for the hard translations Most conversions are mechanical. A few are not, and these are where migrations introduce bugs: - `getDerivedStateFromProps` — usually indicates prop-to-state duplication; the right conversion often deletes the state rather than reproducing it. - `setState`'s second-argument callback — has no direct equivalent; needs to become an effect keyed on the value, or an updater function, depending on which of its two uses applies. - `componentDidUpdate` with previous-props comparisons — becomes a dependency array, and the naive port fires an extra time on mount. - Long-lived instance fields — must be moved deliberately to refs; treating them as ordinary variables in a function body loses them every render. ```jsx // Mechanical: this converts almost by hand. componentDidMount() { document.title = this.props.title; } componentDidUpdate() { document.title = this.props.title; } // → useEffect(() => { document.title = title; }, [title]); ``` ## Make it verifiable The rule I would insist on is that a migration diff changes no behaviour and touches no product logic, and that the component has tests before the conversion rather than after. Mixing a rewrite with a feature change is how a migration acquires a reputation for causing outages, and one visible incident will stop the programme regardless of its merits. ## The judgment being tested The interviewer is checking whether you can say "not all of it, and not now" with reasons. A strong answer names the interop property that makes incrementalism free, ties migration to a capability or a measurement rather than to taste, names the one thing that still needs a class, and shows awareness that a few specific lifecycle translations are where the bugs come from.