State and Context

buildInitialState(items) is an ordinary argument, so JavaScript evaluates it on every render even though React only uses its result on the first one. Pass the raw value plus the function as useReducer's third argument so React calls the initializer only on mount.

A response describes the server at the moment it was serialized; every instant after that it is an assumption. Revalidation triggers are a design decision per data type: after your own mutation, on remount, on tab focus or reconnect, on an interval, on user request, or on a server push.

Nesting order is real dependency order: a provider can only read contexts from providers above it. Tame the pyramid by moving providers down to the subtree that needs them, collecting the rest into one AppProviders component, and folding an ordered array with reduceRight where order is free.

Context has no selector API: React compares the whole value with Object.is and notifies every reader, with no way to opt out per field. The structural fix is to split the value into several contexts along how often each part changes.

Promise that the functions a hook returns keep the same identity for the life of the component, and that data changes identity only when it really changed. Implement stable functions with useCallback plus updater-form updates or a latest-value ref, so no state sits in their dependency list.

Read storage in a lazy useState initializer, not on every render; wrap JSON.parse and every storage call in try/catch because parsing and quota both throw; support functional updates so the write matches the new state; and on the server, where localStorage does not exist, render the initial value and read storage after mount.

Attach a document listener for pointerdown, ignore the event when ref.current contains event.target, and remove the listener in effect cleanup. Keep the handler in a ref refreshed each commit so the subscribing effect depends only on the ref, not on a handler identity that changes every render.

Judge it by how many layers ignore the props and how often the contract changes; one or two hops are fine. The first fix is composition — let the owner build the elements and pass them as children or slot props, so the middle layers never see the data. Context comes after that.

Storing the result adds a second source of truth, a stale frame and an extra render on top of the same computation, so it is strictly worse. Measure first; if the derivation is genuinely hot, use useMemo, which caches within the render and keeps one source of truth.

Put the key on the smallest component that owns exactly the state that should die with the identity change. If that state is mixed with state that must survive, extract the identity-scoped part into its own component and key that one.

Make the transition a function of state and action, not of action alone: switch on the current status first and handle only the actions legal there, returning the state unchanged otherwise. A transition table keyed by state then action expresses the same rule as data.

The first is a remote-control setter: the component decides the new state and the reducer just writes it. The second names what happened and lets the reducer decide the consequences, so the rules live in one place and each user interaction is one action.

An optimistic update must retain the pre-update value so it can be reverted, and must treat the server's response as the truth once it arrives. On failure it reverts to that snapshot and tells the user the action did not happen — a silent revert reads as the app losing their input.

Separate the contexts by role first: most are usually dependency injection of values that never change and should stay. Measure which ones actually update at runtime, how often, how many consumers need slices, and how many non-React readers exist — then migrate only those.

Decide by whether losing the state is the intended product behaviour. If edits are disposable, keyed remount is the simplest correct answer. If they are work the user expects back, the draft must live above the keyed boundary, keyed by record id, and you own its lifetime.

It stops being right once the same entity is read from several places, writes must invalidate other screens, and freshness matters — because at that point you are reimplementing keys, deduplication, revalidation and cache lifetime by hand, inconsistently, in every feature.

Export the Provider and hooks, keep the context object private, and decide deliberately whether the Provider owns state or accepts it as a prop. Then state explicitly whether two mounted instances mean two independent scopes or a misconfiguration you should detect.

Split by concern and lifetime, not by size: each hook should own one source of truth or one subscription. Behaviour-selecting flags are the strongest signal that several hooks were fused, so extract those first and keep a thin composite for existing callers.

A statechart library pays off when flows outgrow a flat status list — nested states, concurrent regions, guards and delays repeated across features, or a graph non-engineers must review. For one component with four states and six transitions, a plain reducer is cheaper and clearer.