react-patterns

React patterns

The rule underneath all of this: an effect synchronises React with something outside React. If nothing outside React is involved, you don't need an effect.

Before you write an effect, try these

Derived data → compute in render.

// Not this
const [visible, setVisible] = useState([]);
useEffect(() => setVisible(filter(todos, query)), [todos, query]);

// This
const visible = filterTodos(todos, query);

Reach for useMemo only when the calculation is measurably expensive and its deps are stable. Justify it by referential stability, and say so in the comment when that's the reason.

Resetting state on prop change → key.

<Profile key={userId} userId={userId} />

"Adjusting" state → hold an id, recompute the object.

const selection = items.find((item) => item.id === selectedId) ?? null;

Event-specific logic → the event handler. If it should run because the user did something, it belongs in the handler. Never toggle state and react to it in an effect. Shared logic across handlers becomes a plain function, not an effect.

No effect chains. An effect whose only job is to set state that triggers another effect is a bug. Compute the whole next state in the initiating handler.

When an effect is correct

Websockets, subscriptions, browser APIs and event listeners, non-React widgets, imperative DOM APIs driven by props or state, and data fetching where no framework-level API exists.

Structure: set up in the body, return a cleanup that fully undoes it.

• Cleanup is mandatory for subscriptions (removeEventListener), async work (AbortController, or an ignore flag), and external instances (disconnect/destroy).
• setup → cleanup → setup again must be safe and idempotent. Strict Mode double-mounts in dev; that's a test, not a nuisance. Never gate an effect with a ref flag to dodge it.
• Effects run after commit. Never rely on one to produce a value needed for the current render.
• useLayoutEffect only for pre-paint work such as a redirect, and comment which warning or flash it prevents.