React Hook Foundations

Question 1

Foundations: useState — what is it used for?

Answer 1

Adds local component state.
setState schedules the next render (state is a per-render snapshot).
Use for UI/local state (inputs, toggles, selection).

Question 2

Foundations: useState — when NOT to use it?

Answer 2

Don’t store derived state (compute from props/state).
Complex transitions → useReducer.
Server data/caching → a cache layer (e.g., React Query).

Question 3

Foundations: useState — top gotchas evaluators flag

Answer 3

• Mutation: never modify objects/arrays in place.
• Stale updates: use functional updates when next depends on prev.
• Not immediate: don’t assume state changed right after setState.

Question 4

Foundations: useState — canonical TS patterns

Answer 4

Type when needed: useState<T | null>(null).
Prev-based: setN(n => n + 1).
Lazy init: useState(() => expensiveInit()).

Question 5

Foundations: useReducer — what is it used for?

Answer 5

State via a reducer: dispatch(action) computes next state.
Use for complex transitions / multiple related fields.
Improves predictability vs many useStates.

Question 6

Foundations: useReducer — when NOT to use it?

Answer 6

Don’t use for simple scalar UI state (prefer useState).
Don’t put async side effects in the reducer (keep reducer pure).
Server state still belongs in a cache layer.

Question 7

Foundations: useReducer — gotchas evaluators flag

Answer 7

• Reducer must be pure (no mutation, no IO).
• Unclear action types → hard to maintain.
• Overloading one reducer for unrelated concerns.

Question 8

Foundations: useReducer — canonical TS patterns

Answer 8

Prefer discriminated unions for actions.
Reducer signature: (state, action) => nextState.
Initialize with stable initialState (or init function if needed).

Question 9

Foundations: useEffect — what is it used for?

Answer 9

Runs side effects after render.
Use to sync with external systems (fetch, subscriptions, timers).
Supports cleanup: return () => ....

Question 10

Foundations: useEffect — dependency array basics

Answer 10

[deps] must include reactive inputs used inside the effect.
Missing deps → stale closure bugs.
Cleanup runs on unmount and before re-run.

Question 11

Foundations: useEffect — when NOT to use it?

Answer 11

Don’t use effects to compute derived UI state.
Don’t mirror props into state unless you truly need it.
Don’t use effect as a general “run code” bucket (prefer event handlers).

Question 12

Foundations: useEffect — top gotchas evaluators flag

Answer 12

• Race: older async result overwrites newer state.
• setState-after-unmount: missing cleanup/abort.
• Infinite loops: effect updates state that retriggers itself.

Question 13

Foundations: useLayoutEffect — what is it used for?

Answer 13

Like useEffect, but runs before paint after DOM mutations.
Use for measure → write to avoid flicker.
Keep work minimal (can block paint).

Question 14

Foundations: useLayoutEffect — when NOT to use it?

Answer 14

Prefer useEffect unless you need layout timing.
Avoid heavy work (jank).
Be careful with SSR (may warn if it runs on server).

Question 15

Foundations: useLayoutEffect — common gotcha

Answer 15

Overuse causes render blocking / jank.
If you’re not measuring layout, it’s usually the wrong tool.

Question 16

Foundations: useMemo — what is it used for?

Answer 16

Memoizes a computed value.
Recomputes only when deps change.
Use for expensive compute or stable derived objects/arrays.

Question 17

Foundations: useMemo — when NOT to use it?

Answer 17

Don’t memoize trivial work (overhead > benefit).
Don’t use it as correctness glue for missing deps.
If nothing depends on reference identity, skip it.

Question 18

Foundations: useMemo — gotchas evaluators flag

Answer 18

• Wrong deps → stale values.
• Unstable deps: including an object/array literal created every render defeats memoization.
• “Memo everywhere”: adds noise without measured benefit (prefer profiling evidence).

Question 19

Foundations: useCallback — what is it used for?

Answer 19

Memoizes a function identity.
Use when passing callbacks to React.memo children or effect deps.
Helps with referential stability.

Question 20

Foundations: useCallback — when NOT to use it?

Answer 20

Don’t wrap every handler by default.
If the callback isn’t a dependency and not passed to memoized children, skip it.
Premature optimization can harm readability.

Question 21

Foundations: useCallback — gotchas evaluators flag

Answer 21

• Wrong deps → callback reads stale state/props.
• Assuming it prevents rerenders by itself (it doesn’t).
• Overuse increases cognitive load.

Question 22

Foundations: useRef — what is it used for?

Answer 22

Persistent mutable container: ref.current survives renders.
Updating it does not rerender.
Use for DOM refs or instance values (timers, previous values).

Question 23

Foundations: useRef — when NOT to use it?

Answer 23

• If the UI must update when the value changes → use state.
• If rendering depends on it, useRef can cause ghost UI (data changes, screen doesn’t).
• Avoid heavy imperative DOM manipulation that fights React.

Question 24

Foundations: useRef — gotchas evaluators flag

Answer 24

• Using ref as state (UI doesn’t rerender).
• Mutating ref during render in concurrency-sensitive flows.
• Imperative DOM hacks that fight React reconciliation.

Question 25

Foundations: useRef — canonical patterns

Answer 25

DOM ref: `const inputRef = useRef(null)`. Prev value: update `ref.current` in an effect. Timer id: store in ref; clear in cleanup.

Question 26

Foundations: useContext — what is it used for?

Answer 26

Reads from nearest matching **Context Provider**. Use to share app-wide concerns (theme, auth, i18n) without prop drilling. Consumers rerender when provider value identity changes.

Question 27

Foundations: useContext — when NOT to use it?

Answer 27

Don't put fast-changing/high-churn values in a top-level context. Don't use one giant context for unrelated values. Sometimes composition/props is simpler.

Question 28

Foundations: useContext — gotchas evaluators flag

Answer 28

- Provider too high + hot value → **rerender flood**. - **Object literal trap:** `value={{ user }}` changes identity every render; stabilize with `useMemo` or pass primitives. - Missing provider guard → `null`/`undefined` context crashes.

Question 29

Foundations: useTransition — what is it used for?

Answer 29

Marks updates as **non-urgent** to keep UI responsive. Gives `isPending` and `startTransition`. Use for expensive UI updates triggered by user input.

Question 30

Foundations: useTransition — when NOT to use it?

Answer 30

Not a correctness fix. If the render isn't expensive, it adds complexity. Doesn't replace memoization/virtualization when needed.

Question 31

Foundations: useTransition — gotchas evaluators flag

Answer 31

Using it to hide performance problems without addressing root cause. Forgetting to keep urgent updates outside the transition.

Question 32

Foundations: useDeferredValue — what is it used for?

Answer 32

Provides a **deferred** version of a value. Urgent updates render first; deferred value lags. Use to keep inputs responsive while expensive results render.

Question 33

Foundations: useDeferredValue — when NOT to use it?

Answer 33

It doesn't reduce compute cost by itself. If you need correctness/consistency, don't rely on deferred values. Not a substitute for caching.

Question 34

Foundations: useDeferredValue — gotchas evaluators flag

Answer 34

Expecting it to fix slow renders without optimizing compute/render. Using it where stale results are unacceptable.

Question 35

Foundations: useSyncExternalStore — what is it used for?

Answer 35

Subscribe to an **external store** safely under concurrent rendering. Prevents tearing by coordinating subscription + snapshot reads. Use for custom stores / external state containers.

Question 36

Foundations: useSyncExternalStore — when NOT to use it?

Answer 36

Don't use for local component state. If you're using a library integration that already handles it, don't rewrap. Avoid ad-hoc subscribe hooks that ignore concurrency.

Question 37

Foundations: useSyncExternalStore — gotchas evaluators flag

Answer 37

- **Snapshot caching trap:** if `getSnapshot` returns a new object each call, React can re-render indefinitely ("getSnapshot should be cached"). - Snapshot not stable/consistent → tearing. - Subscribe/unsubscribe bugs (leaks / missed updates).

Question 38

Foundations: useActionState — what is it used for? (React 19)

Answer 38

Manages **action-driven state** for async mutations (often forms). Returns: **state + action dispatcher + pending** (conceptually). Use to avoid scattered `loading/error/result` state.

Question 39

Foundations: useActionState — naming note (compat)

Answer 39

Formerly seen as `useFormState` in earlier canary/framework docs. Evaluator-safe phrasing: "`useActionState` (aka earlier `useFormState`)".

Question 40

Foundations: useActionState — when NOT to use it?

Answer 40

Don't use for pure synchronous UI state. If a server-state library owns mutation state, avoid duplicating it. Don't cross client/server boundaries with secrets.

Question 41

Foundations: useActionState — gotchas evaluators flag

Answer 41

- **Dispatch context trap:** calling the returned action outside a `

` / `button formAction` (or outside `startTransition`) can warn and pending tracking may not behave as intended. - Manual tri-state spaghetti instead of action-driven state. - Missing error/result handling from the action.

Question 42

Foundations: useOptimistic — what is it used for?

Answer 42

Optimistic UI state: show expected result **before** server confirms. Use with mutations to keep UX snappy. Pair with rollback/invalidation on settle.

Question 43

Foundations: useOptimistic — when NOT to use it?

Answer 43

- Don’t use if you can’t safely roll back. - **Prediction gap:** if the server must compute the next state (e.g., DB-generated IDs), optimistic state may be wrong. - Avoid when inconsistency is unacceptable.

Question 44

Foundations: useOptimistic — gotchas evaluators flag

Answer 44

- No rollback/compensation on error. - Optimistic updates that diverge from server truth. - Forgetting to reconcile with refetch/invalidation.

Question 45

Foundations: useId — what is it used for?

Answer 45

Generates **stable unique IDs** across server/client rendering. Use for a11y wiring: `label` ↔ `input` / `aria-describedby`. Helps avoid hydration mismatches for IDs.

Question 46

Foundations: useId — when NOT to use it?

Answer 46

Not for list keys. Not for security tokens. If a stable id comes from data (DB id), use that instead.

Question 47

Foundations: useImperativeHandle — what is it used for?

Answer 47

Customize the **ref API** a component exposes. Requires `forwardRef`. Expose small, intentional imperative methods (`focus`, `scrollTo`).

Question 48

Foundations: useImperativeHandle — when NOT to use it?

Answer 48

Prefer declarative props/state when possible. Don't expose large surface areas or internal DOM details. Avoid unless consumers truly need imperative control.

Question 49

Foundations: useImperativeHandle — gotchas evaluators flag

Answer 49

- Overusing imperative APIs increases coupling. - Exposing unstable methods/objects without memoization. - Using refs to work around poor component API design.

Question 50

Foundations: useEffectEvent — what is it used for?

Answer 50

Creates a stable callback that can read the **latest** props/state without forcing effects to re-run for those values. Use to avoid stale closures in event-like logic.

Question 51

Foundations: useEffectEvent — when to reach for it

Answer 51

- When an effect should re-run for **A**, but must read the latest **B** without making **B** a dependency. - Keeps deps focused on true triggers. - Reduces "dependency wars" and avoids accidental loops.

Question 52

Foundations: useEffectEvent — gotchas evaluators flag

Answer 52

- Treating it like a general-purpose hook everywhere. - Forgetting normal hook rules still apply (top-level call). - Using it to hide architectural problems (over-coupled effects).

Question 53

Foundations: useFormStatus — what is it used for? (react-dom)

Answer 53

Reads **form submission status** from the nearest `` context. Commonly used to disable submit buttons / show pending UI. Designed for actions-based form flows.

Question 54

Foundations: useFormStatus — critical call-site rule

Answer 54

Must be called from a component **rendered inside** the ``. If called outside, `pending` won't reflect the form's status.

Question 55

Foundations: useFormStatus — gotchas evaluators flag

Answer 55

- Calling it outside the form → `pending` always false. - Double-submit risk if pending isn't respected. - Confusing it with generic loading state.

Question 56

Foundations: `use` (React API) — what is it?

Answer 56

`use(resource)` is a React **API** (not a Hook). It can read a **Promise** or **Context** and integrate with Suspense. Key distinction: different call-site rules vs Hooks.

Question 57

Foundations: `use` — call-site rules (trap)

Answer 57

Hooks must be called **top-level**. `use(...)` can be called in **conditionals/loops**. Evaluator tell: don't call it "a hook".

Question 58

Foundations: `use` — when to use it

Answer 58

When consuming a resource that may suspend (Promise) or a Context in places where Hook rules would be awkward. Use in environments that support Suspense-based data flows.

Question 59

Foundations: `use` — gotchas evaluators flag

Answer 59

- **Boundary trap:** `use(promise)` suspends; you need a parent `` fallback (and an Error Boundary for rejections) for safe UX. - Don’t create Promises in Client Components on every render (unstable). - Avoid client/server boundary mistakes (secrets / non-serializable values).