Class Components and Legacy Code

New words in this topic, in plain English. Come back here whenever one feels fuzzy.

Class component

A component written as a class that extends Component and has a render() method.

this.state / this.setState

A class component's state object and the method that merges changes into it and schedules a render.

Lifecycle method

A method React calls at a certain moment: after mounting, after updating, before unmounting.

componentDidMount

Runs once after the component first appears in the DOM.

componentDidUpdate

Runs after every update, with the previous props and state, so you can compare.

componentWillUnmount

Runs just before the component is removed: clean up timers and subscriptions here.

PureComponent

A class base that skips rendering when props and state are shallowly equal.

Error boundary

A class component that catches render errors in its children and shows a fallback.

Binding

Fixing what this refers to inside a method, needed when the method is passed as a handler.

1. 1

   Return false from shouldComponentUpdate

   In the lifecycle example, make shouldComponentUpdate return false. Predict the log after the click and what the button shows. (After the click only getDerivedStateFromProps, shouldComponentUpdate and the setState callback log: there's no render and no componentDidUpdate, and the button still says 0 likes. The callback shows likes = 1: the state changed, but React skipped rendering it.)

2. 2

   Lose this

   In the setState example, change addTwiceRight = () => { to a normal method addTwiceRight() {. Click the button in the preview and read the console: this is undefined inside the handler. Fix it with onClick={() => this.addTwiceRight()} or by binding in a constructor.

3. 3

   Replace gDSFP with a key

   Delete getDerivedStateFromProps and the userId field from EditName, and render <EditName key={users[i].id} user={users[i]} />. The output stays the same: a new key mounts a fresh component with fresh state.

Errors are the best teachers. Make each change, read the error, guess what went wrong, then reveal the answer.

1. 1

   A class component is a JavaScript class (see /javascript, classes) that extends Component from React and has a render() method returning JSX. Props arrive as this.props. State is one object, this.state, set in the constructor (after calling super(props)) or with a class field state = { ... }. Methods that are passed as event handlers must keep the right this: write them as arrow-function class fields (handleClick = () => { ... }) or bind them in the constructor, otherwise this is undefined when React calls them.

2. 2

   this.setState(partial) merges the object you pass into the existing state (only top-level keys), unlike useState's setter, which replaces the value. Updates are batched exactly like hooks updates, so this.state doesn't change until the next render: calling this.setState({ count: this.state.count + 1 }) twice adds one. The fix is the same as with hooks, an updater function: this.setState((prev) => ({ count: prev.count + 1 })). A second argument is a callback that runs after the update is committed, the class equivalent of reacting to a change in an effect.

3. 3

   Lifecycle methods, in order. Mounting: constructor → static getDerivedStateFromProps → render → (DOM updated) → componentDidMount. Updating: getDerivedStateFromProps → shouldComponentUpdate → render → getSnapshotBeforeUpdate (reads the DOM just before it changes, e.g. scroll position) → componentDidUpdate(prevProps, prevState, snapshot). Unmounting: componentWillUnmount. The first group is the render phase and must be pure; getSnapshotBeforeUpdate runs in the commit's before-mutation step; componentDidMount/Update run in the layout step, at the same time as useLayoutEffect (Topic 26.1).

4. 4

   Performance controls. shouldComponentUpdate(nextProps, nextState) returns false to skip a render. **PureComponent** implements it for you with a shallow comparison of props and state, the class version of memo (Topic 16.3). **static getDerivedStateFromProps(props, state)** returns an object to merge into state before every render (or null); its only good use is resetting some state when a prop like an id changes, and even that is usually better done with a key (Topic 6.4). The old componentWillMount, componentWillReceiveProps and componentWillUpdate are unsafe in concurrent rendering and are only available with an UNSAFE_ prefix.

5. 5

   Error boundaries (Topic 14.5) are the one thing hooks can't do. A class with static getDerivedStateFromError(error) (render phase: return state that switches to a fallback UI) and/or componentDidCatch(error, info) (commit phase: log or report it) catches errors thrown while rendering its children, in their lifecycle methods and constructors. It does not catch errors in event handlers, async code or itself. Most teams write one boundary class once, or use the react-error-boundary package, and never write another class.

6. 6

   Migrating to hooks is done one component at a time; classes and function components mix freely in one tree. The mapping: this.state → one useState per independent value (or useReducer); componentDidMount + componentDidUpdate + componentWillUnmount doing one job → one useEffect with the right dependencies and a cleanup; instance fields like this.timer → useRef; shouldComponentUpdate/PureComponent → memo; getDerivedStateFromProps → compute during render or reset with key; getSnapshotBeforeUpdate → useLayoutEffect with a ref; this.setState(x, callback) → an effect that reacts to the new value, or do the work in the handler. Cover the component with behaviour tests first (Phase 17) so you know the migration changed nothing visible.

• ↔

  Migrating a working class costs time and risk; migrate when you are changing the component anyway, or when it blocks using a hook-based library.

• ↔

  Classes group code by *when* it runs (lifecycle); hooks group it by *what* it does (one effect per concern), which is easier to reuse through custom hooks.

• I can read a class component and point out its state, handlers and lifecycles.

• I can explain setState merging, batching, updaters and the callback.

• I can list the lifecycle methods in order and map each to hooks.

• I can write an error boundary class.

• I can migrate a class to hooks without changing its behaviour.