State and Context

React Context is a dependency-injection channel, not a state manager: it carries one value down the tree so descendants can read it without prop drilling. It stores nothing itself — the state still lives in useState, useReducer, or an external store.

Extract a custom hook when the logic calls other hooks, or when the same hook wiring repeats across components. If the logic is a pure computation over its arguments, keep it a plain function outside the component.

Move the state into the siblings' nearest common ancestor. That parent owns it with useState and passes the current value down to both children, plus a callback that lets the editing child ask for a change.

fullName is derivable, so storing it duplicates state. The effect runs after React commits, so the screen briefly shows a stale name and every keystroke costs a second render pass. Compute it during render as a plain const.

Three independent booleans allow eight combinations, and most are nonsense — loading and error both true, or success true with no data. Replace them with one status value (idle, loading, success, error) so contradictory states cannot be represented at all.

Fetched API data is a local cache of state the server owns: shared with other users, able to go stale, needing refetch and invalidation. Client state such as an open dropdown is owned entirely by this browser tab and is never stale.

The hook turns "you forgot the Provider" into an immediate, named error at the misuse site instead of a null that spreads through the app. Create the context with null, read it in the hook, throw if it is null, and export only the hook and the Provider.

The object literal creates a new object on every render, so React sees a new context value each time and notifies all consumers. Wrap the value in useMemo keyed on its real dependencies, and keep the functions stable too.

No. A custom hook shares logic, not state: every call site gets its own independent state, so the two counters are unrelated. Sharing one value requires lifting it to a common parent, putting it in context, or using an external store.

useDebouncedValue keeps a state copy updated by an effect that starts a timeout and clears it in cleanup, so each new value restarts the delay. A callback version must keep the newest fn in a ref, because a debounced wrapper created once would otherwise fire a frozen closure.

The argument to useState is only the initial value: React reads it on the component instance's first render and ignores it afterwards, so the copy freezes. Either derive from the prop directly, or treat the copy as genuinely separate state with an explicit reset.

Prefer the key: rendering the form with key set to the record id makes React unmount the old instance and mount a fresh one, so every piece of state inside resets at exactly the right moment, with no reset code to keep in sync.

React runs reducers during rendering and may call one twice in development, so a reducer must only compute and return the next state from its arguments. Fetching, logging, storage writes, timers and randomness belong in the event handler or an effect.

Move to useReducer when several state fields change together on one event, when the next value depends on the previous one, or when the same update logic is repeated across handlers. You gain a single pure transition function you can test on its own.

Each copy fires its own request, ages independently, and is updated independently, so the two components drift apart and there is no single place to invalidate after a write. One entry keyed by the entity, shared by both readers, gives one request, one truth and one invalidation point.

Move to a store when many consumers each need a different slice of frequently-changing state, when non-React code reads or writes it, or when you need middleware, devtools and persistence. Stay with Context for rarely-changing values consumed whole.

createContext's argument is the value a consumer receives when no matching Provider sits above it in the tree. If a Provider is present but passes undefined, the consumer gets undefined — the default is not a general fallback.

useToggle holds a boolean in useState and returns it with a toggler that calls setOn(v => !v). The updater form flips whatever the newest value is, so the toggle is still correct when the captured value is stale or two flips land in one event.

React guarantees that the dispatch function keeps the same identity for the whole lifetime of the component, so listing it in a dependency array can never cause the effect to re-run. That stability also means dispatch needs no useCallback when passed to memoized children.

It reads "light": React returns the nearest matching Provider above the reader, and values do not merge. Deliberate nesting scopes a value to a subtree — a local override, or a fresh independent instance of a Provider that owns state.

Components that only trigger updates do not need the state. Putting the updater in its own context gives it a value that never changes, so those write-only components stop re-rendering every time the state changes.

Context values are only readable from a component rendering under the provider, during render, so plain modules cannot reach them. Keep the token in a module-level store that any code can read and write, and expose it to components with useSyncExternalStore.

Return a tuple for two or three positional values callers will frequently rename, as useState does. Return an object once there are several values or the set may grow, because names document meaning and adding a field breaks no existing caller.

Store the value in a useRef and overwrite it inside a useEffect that runs after every render, returning ref.current first. Reading before the effect writes yields the previous render's value; on the first render it is undefined.

State belongs in the lowest component that needs it. Hoisting a table's search string to the page re-renders the whole screen on every keystroke, piles unrelated concerns into one component, and stops the table from being usable on its own.

Support both modes: seed internal state from a defaultValue prop, and treat the component as controlled whenever a value prop is supplied. Controlled, it renders the parent's value and only reports changes; uncontrolled, it updates its own state.

Storing the object duplicates data the rows prop already owns, so the stored copy goes stale when rows are refetched or edited. Store the id — the minimal fact React cannot compute — and look the row up during render.

The key is derived from content that changes while the component is alive, so every keystroke is a new identity and React remounts the editor, destroying the focused element. Key on the stable identity being edited, such as the author or comment id.

Model the state as a discriminated union: one object variant per status, each declaring only the fields that status owns. Narrowing on status then makes data available only in the success variant and error only in the error variant, so nullable-everywhere fields disappear.