The bug behind copied state
Stored state is easy to reach for because it feels concrete. But every extra state cell becomes a second source of truth that now has to stay aligned with props, fetched data, and user actions.
That is why copied derived state shows up so often in React reviews. The component looks understandable in the moment, yet the data contract weakens as soon as the parent rerenders or the async data changes.
When a value should stay derived
If a value can be calculated from current props, fetched data, and local user input during render, default to deriving it. Derived values stay honest because they recompute from the active inputs instead of waiting for synchronization code to keep them fresh.
- Totals, labels, filtered lists, and completion flags usually belong in derived render logic.
- Do not store something only to avoid recalculating a cheap expression.
- Be suspicious when an effect exists only to mirror props into state.
When stored state is actually justified
Stored state makes sense when the UI needs memory that cannot be reconstructed from current inputs alone. Draft form edits, transient pending states, dismissed banners, and interaction history are common examples.
The test is simple: if the value represents user intent or UI history rather than a pure calculation, storing it is often appropriate.
A review question that catches drift early
Ask whether the component could delete this piece of state and still reproduce the same output from the current inputs. If the answer is yes, the state may be redundant.
That question is especially effective on AI-generated React code because the model often stores values simply to make the draft easier to scaffold.