Migrate a class component to hooks without silently dropping lifecycle behavior

You are migrating a class component to a function component with hooks. You preserve the exact same behavior — this is a mechanical migration, not an opportunity to also redesign the component or fix unrelated issues you notice along the way.

CLASS COMPONENT
class UserPanel extends React.Component { constructor(props) { super(props); this.state = { user: null, loading: true }; } componentDidMount() { this.fetchUser(); } componentDidUpdate(prevProps) { if (prevProps.userId !== this.props.userId) this.fetchUser(); } componentWillUnmount() { this.controller?.abort(); } }

LIFECYCLE METHODS IN USE
componentDidMount, componentDidUpdate, componentWillUnmount, shouldComponentUpdate

ERROR BOUNDARY LOGIC
No, this specific component has no error-boundary logic.

TARGET REACT VERSION
React 19

MIGRATION MAP
Map each lifecycle method explicitly, and flag any that do not have a clean 1:1 hook equivalent rather than inventing a workaround to claim full completion. The constructor's this.state becomes one or more useState calls, split by what actually changes together, not collapsed by default into one giant state object just because that mirrors the original this.state shape. componentDidMount and componentDidUpdate, when they run the exact same logic, become a single useEffect with the correct dependency array; if they run genuinely different logic in the class version, that is a sign they need to become two separate useEffect calls in the function version rather than one merged effect with awkward conditionals recreating the class's implicit branching inside it. componentWillUnmount becomes the cleanup function returned from the relevant useEffect. shouldComponentUpdate becomes React.memo on the component, with a custom comparator only if the default shallow-equality comparison is provably insufficient for this specific component's props. getDerivedStateFromProps is usually a sign the value should be computed during render instead of stored in state at all — if that is true here, recommend removing the state entirely rather than mechanically translating it into a hook. Instance variables that do not trigger a re-render, such as this.someRef or a mutable counter, become useRef. Error boundaries — componentDidCatch and static getDerivedStateFromError — have no hook equivalent as of the target React version; leave that logic as a class component and state that explicitly rather than inventing a hook-based substitute that would silently stop catching errors. static contextType or a Context.Consumer render-prop pattern used to read context becomes a direct useContext(SomeContext) call at the top of the function body — a strict simplification with no behavior difference, worth naming explicitly since a static class property is easy to miss when scanning a class component specifically for lifecycle methods. defaultProps defined as a static class property becomes default values in the function's own parameter destructuring — function Component({ size = 'medium' }) — rather than a separate defaultProps object kept alongside a function component, where recent React versions no longer give it any special meaning at all.

OUTPUT FORMAT
1. The migrated function component, as complete code.
2. A mapping table: old lifecycle method to new hook, with one line on any behavior difference, however small, introduced by the change.
3. Anything left as a class component per the error-boundary rule above, and exactly why.