Deck 17 - Data Fetching + Caching Patterns

Question 1

Deck 17 - Data Fetching + Caching Patterns (React Query/SWR style) (objective)

Answer 1

Goal: review async data code like a senior: caching, invalidation, query keys, optimistic updates, retries, pagination, and edge cases.
You learn: what/why (under the hood), common bugs, and evaluator-grade review wording.
Output style: PASS/PARTIAL/FAIL + 2-3 issues + fix approach.

Question 2

Mental model: server state vs client state (again, in caching terms).

Answer 2

Server state is remote and can be stale; it needs caching, invalidation, and refetch.
Client state is local and authoritative (UI toggles, selections).

Question 3

Mental model: cache key is the identity of data.

Answer 3

Query keys define what data is cached.
If the key is wrong/unstable, you get collisions, refetch storms, or stale data.

Question 4

Mental model: stale vs fresh vs invalidated.

Answer 4

Fresh: within staleTime. Stale: eligible to refetch. Invalidated: marked stale now.
Stale does not mean wrong; it means revalidation may run.

Question 5

Mental model: deduping and request coalescing.

Answer 5

Libraries dedupe in-flight requests for same key.
Without it, components can trigger duplicate network calls.

Question 6

Mental model: retries are not always safe.

Answer 6

Retrying POST/PUT can duplicate writes unless idempotent.
Prefer retries for GET; for mutations, ensure idempotency or disable retries.

Question 7

Mental model: optimistic update is a temporary local illusion.

Answer 7

You update cache immediately, then confirm or roll back.
Requires rollback logic and careful invalidation on settle.

Question 8

Mental model: ‘keep previous data’ vs flicker.

Answer 8

Keeping previous data avoids UI flicker during refetch.
But can show stale content; use loading indicators or ‘updating’ state.

Question 9

Mental model: background refetch triggers.

Answer 9

Focus/reconnect/refetchInterval can refetch unexpectedly.
Reviewer: ensure it is intentional and not causing rate limits.

Question 10

Mental model: pagination and cache shape.

Answer 10

Paginated data can be cached per page or as an infinite list.
Wrong key/merge strategy can duplicate items or break ordering.

Question 11

Mental model: normalization vs caching per query.

Answer 11

React Query caches per query response.
Normalization can help large graphs but increases complexity; use when needed.

Question 12

Mental model: cancellation and race protection.

Answer 12

Requests should be cancellable (AbortController) or at least guarded against stale responses.
Libraries handle some races; manual fetch needs explicit guard.

Question 13

Mental model: error states are part of UX contract.

Answer 13

Handle loading/error/empty states consistently.
Do not treat errors as just console logs.

Question 14

Mental model: validation at the boundary.

Answer 14

Treat API responses as unknown; validate (Zod) at boundary.
Prevents runtime crashes from unexpected shapes.

Question 15

Mental model: cache invalidation is a correctness problem.

Answer 15

If you forget invalidation, UI shows stale data.
If you over-invalidate, you cause refetch storms.

Question 16

Mental model: queryFn purity.

Answer 16

Query functions should be deterministic for a given key.
They should not depend on unstable closures or mutable globals.

Question 17

Mental model: suspense vs manual loading.

Answer 17

Suspense centralizes loading handling.
But requires boundaries and can complicate error handling; match approach to app needs.

Question 18

Mental model: auth tokens and caching.

Answer 18

Cache may contain user-specific data.
On logout/login, clear caches or scope keys by user to avoid leaking data across sessions.

Question 19

Mental model: prefetching improves perceived performance.

Answer 19

Prefetch likely next data (hover, route transition).
But avoid wasteful prefetch that spikes bandwidth.

Question 20

Mental model: selecting and transforming data.

Answer 20

Use ‘select’ to derive view models in query layer.
Keeps UI components simpler and avoids repeated transforms.

Question 21

Pattern: stable query keys (rule).

Answer 21

Keys should be arrays with stable primitives.
Example: [‘user’, userId] not [‘user’, { id: userId }] unless object is stable/serialized.

Question 22

Pattern: include all params in key.

Answer 22

Search/sort/page/filter params must be part of key.
Otherwise cached results can be returned for wrong inputs.

Question 23

Pattern: use enabled for conditional queries.

Answer 23

If a query depends on an ID, set enabled: !!id.
Prevents fetching with undefined and reduces error noise.

Question 24

Pattern: staleTime vs cacheTime (concept).

Answer 24

staleTime controls refetch eligibility; cacheTime controls how long unused data stays in memory.
Tune to UX and data volatility.

Question 25

Pattern: invalidate on mutation success.

Answer 25

After mutation, invalidate related queries (or update cache directly). Pick minimal invalidation to avoid unnecessary refetches.

Question 26

Pattern: optimistic update with rollback (steps).

Answer 26

1) cancel queries 2) snapshot previous 3) update cache 4) rollback on error 5) invalidate on settle.

Question 27

Pattern: avoid retrying non-idempotent mutations.

Answer 27

Retries can create duplicates. If mutation is idempotent, include idempotency key and document it.

Question 28

Pattern: keepPreviousData for pagination.

Answer 28

Avoid flicker when switching pages. Show an 'updating' indicator to communicate staleness.

Question 29

Pattern: debounce user input queries.

Answer 29

Debounce search input to reduce request storms. Use stable debounced value as key param.

Question 30

Pattern: abort/cancel in-flight when changing params.

Answer 30

Libraries often cancel on new fetch; ensure underlying fetch respects abort. For custom fetch: pass AbortController signal.

Question 31

Pattern: handle empty state separately from error.

Answer 31

Empty results is a valid state; errors are failures. Provide distinct UI messages.

Question 32

Pattern: schema validation at boundary (Zod).

Answer 32

Parse unknown JSON into typed models. On validation failure: treat as error and log safely.

Question 33

Pattern: select to compute view models.

Answer 33

Use select to transform data once at cache boundary. Reduces repeated mapping in UI and improves consistency.

Question 34

Pattern: cache scoping by user.

Answer 34

Include userId in query keys or clear cache on auth changes. Prevents showing prior user's data.

Question 35

Pattern: prefetch on navigation intent.

Answer 35

Prefetch route data on hover or when link becomes visible. Reduces perceived latency.

Question 36

Pattern: refetchOnWindowFocus tradeoff.

Answer 36

Improves freshness but can annoy users and stress APIs. Disable or tune if data is not volatile.

Question 37

Pattern: error retries with backoff.

Answer 37

Use exponential backoff for transient failures. Cap retries to avoid infinite loops.

Question 38

Pattern: infinite queries (high level).

Answer 38

Use cursor-based pagination when possible. Merge pages carefully and dedupe items by stable IDs.

Question 39

Pattern: dedupe and normalize list updates (practical).

Answer 39

When merging pages or optimistic updates, dedupe by id. Prevents duplicates and broken keys.

Question 40

Pattern: consistent loading UI strategy.

Answer 40

Use skeletons for initial load; subtle 'updating' indicator for background refetch. Avoid full-page spinners for minor refetch.

Question 41

Gotcha: unstable query key object. ``` useQuery({ queryKey: ['user', { id }], queryFn: () => fetchUser(id) }) ```

Answer 41

PARTIAL - Object in key can be unstable. Use primitives or stable serialization. Prefer ['user', id].

Question 42

Gotcha: missing params in key. ``` useQuery({ queryKey: ['search'], queryFn: () => search(q) }) ```

Answer 42

FAIL - Cache collision: different q shares same key. Include q in key: ['search', q].

Question 43

Gotcha: fetch runs with undefined id. ``` useQuery({ queryKey: ['user', id], queryFn: () => fetchUser(id) }) ```

Answer 43

FAIL - If id can be undefined, queryFn may crash or hit wrong endpoint. Use enabled: !!id and guard.

Question 44

Gotcha: mutation does not invalidate cache.

Answer 44

FAIL - UI can remain stale after mutation. Invalidate related queries or update cache directly on success.

Question 45

Gotcha: optimistic update without rollback.

Answer 45

FAIL - If mutation fails, UI stays wrong. Snapshot previous cache and rollback on error.

Question 46

Gotcha: retrying non-idempotent mutation.

Answer 46

FAIL - Retries can duplicate writes. Disable retry or implement idempotency keys.

Question 47

Gotcha: queryFn uses unstable closure. ``` const fn = () => fetch(`/api?q=${q}`); useQuery({ queryKey: ['search', q], queryFn: fn }) ```

Answer 47

PARTIAL - It's okay if q is in key, but ensure queryFn uses key param or stable dependencies to avoid confusion. Prefer queryFn receives key params.

Question 48

Gotcha: manual fetch in useEffect duplicates library cache.

Answer 48

PARTIAL - Two sources of truth (manual state + query cache) drift. Prefer a single server-state approach (React Query/SWR).

Question 49

Gotcha: over-invalidation (refetch storm).

Answer 49

PARTIAL - Invalidating broad keys causes excessive refetches. Invalidate the smallest key set needed.

Question 50

Gotcha: cache not cleared on logout.

Answer 50

FAIL - Can leak prior user's data. Clear query cache on logout or scope keys by user/session.

Question 51

Gotcha: stale UI without 'updating' signal.

Answer 51

PARTIAL - keepPreviousData may show old page results. Provide subtle updating indicator and disable actions if needed.

Question 52

Gotcha: using index keys after pagination merge.

Answer 52

FAIL - Duplicates/reordering can break list identity. Use stable ids and dedupe merges.

Question 53

Gotcha: no error boundary for query errors (UX).

Answer 53

PARTIAL - Ensure errors are handled and shown consistently. Use error UI and retries where appropriate.

Question 54

Gotcha: parsing JSON without validation at boundary.

Answer 54

FAIL - Unknown data shape can crash UI. Validate with schema and treat invalid response as error.

Question 55

Gotcha: refetch on focus causing rate limits.

Answer 55

PARTIAL - Might hammer APIs. Tune refetchOnWindowFocus and staleTime, especially for expensive endpoints.

Question 56

Mini-drill: reviewer wording for missing query key params.

Answer 56

FAIL - Query key does not include input params, causing cache collisions and incorrect results. Include params in key (e.g., ['search', q]).

Question 57

Mini-drill: reviewer wording for missing invalidation.

Answer 57

FAIL - Mutation updates server but cache is not updated or invalidated, leaving UI stale. Invalidate affected queries or update cache on success.

Question 58

Mini-drill: reviewer wording for optimistic update rollback.

Answer 58

FAIL - Optimistic update lacks rollback path on error. Snapshot previous cache and restore on failure; invalidate on settled.

Question 59

Mini-drill: reviewer wording for logout cache leak.

Answer 59

FAIL - Server cache can persist across sessions, showing prior user's data. Clear query cache on logout or scope keys by user/session.

Question 60

Mini-drill: reviewer wording for over-invalidation.

Answer 60

PARTIAL - Invalidation is overly broad and can trigger refetch storms. Narrow invalidation to the smallest affected query keys.

Question 61

Mini-drill: reviewer wording for retries on mutation.

Answer 61

FAIL - Retrying non-idempotent mutations can duplicate writes. Disable retries or implement idempotency and document it.

Question 62

Mini-drill: checklist for query key correctness.

Answer 62

1) Stable primitives 2) Includes all inputs 3) Scoped by user/session when needed 4) No collisions across features 5) Matches queryFn behavior

Question 63

Mini-drill: when to prefetch.

Answer 63

Prefetch when probability of navigation is high (hover/near viewport) and data is reusable. Avoid prefetching large/rarely used data.

Question 64

Mini-drill: when to use keepPreviousData.

Answer 64

Use for pagination/filter changes to prevent flicker, but provide an 'updating' indicator and keep keys correct to avoid misleading UI.

Question 65

Mini-drill: difference between staleTime and cacheTime.

Answer 65

staleTime: how long data is considered fresh before refetch. cacheTime: how long unused data stays before garbage collected.

Question 66

Checklist: server state review top 10.

Answer 66

1) Correct query keys 2) enabled guards 3) Cancellation/race protection 4) Clear loading/error/empty states 5) Validation at boundary 6) Invalidation/update strategy 7) Optimistic update rollback 8) Retry policy correctness 9) Pagination merge/dedupe 10) Auth/session cache scoping

Question 67

Example: stable key + enabled. ``` useQuery({ queryKey: ['user', userId], enabled: !!userId, queryFn: () => fetchUser(userId!), }); ```

Answer 67

PASS - Key includes id and query is disabled until id exists.

Question 68

Example: optimistic update skeleton (high level). ``` onMutate: async (vars) => { await qc.cancelQueries({ queryKey: ['items'] }); const prev = qc.getQueryData(['items']); qc.setQueryData(['items'], (old) => optimistic(old, vars)); return { prev }; }, onError: (_err, _vars, ctx) => { qc.setQueryData(['items'], ctx?.prev); }, onSettled: () => { qc.invalidateQueries({ queryKey: ['items'] }); } ```

Answer 68

PASS - Cancel + snapshot + update + rollback + invalidate on settled.

Question 69

Example: pagination key includes page params. ``` useQuery({ queryKey: ['search', q, page, sort], queryFn: () => search({ q, page, sort }), keepPreviousData: true, }); ```

Answer 69

PASS - Cache correctness for different pages/sorts; avoids flicker.

Question 70

Example: validate response at boundary. ``` const Data = Schema.parse(await res.json()); return Data; ```

Answer 70

PASS - Treats API response as unknown and validates before UI uses it.

Question 71

Anti-pattern: local state copy of query data (why).

Answer 71

Copying query data into useState causes drift and extra effects. Prefer using query data directly or use select for derived values.

Question 72

Anti-pattern: key mismatch with queryFn.

Answer 72

If queryFn reads q but key omits q, cache serves wrong results. Rule: queryFn must be a function of the key inputs.

Question 73

Anti-pattern: invalidating all queries on any mutation.

Answer 73

Overly broad invalidation triggers refetch storms. Invalidate only the affected keys or update cache precisely.

Question 74

Mini-drill: write a one-sentence verdict for cache leak.

Answer 74

FAIL - Cached server data is not scoped or cleared on auth changes, risking cross-user data exposure.

Question 75

Mini-drill: write a one-sentence verdict for key collision.

Answer 75

FAIL - Query key does not include required parameters, causing cache collisions and incorrect results across different inputs.

Question 76

Mini-drill: what edge cases to test for pagination.

Answer 76

Empty page, last page boundary, rapid page changes, dedupe across pages, error on next page, and preserving selection across page changes.

Question 77

Mini-drill: what edge cases to test for optimistic updates.

Answer 77

Server error rollback, partial failures, concurrent mutations, out-of-order responses, and reconciliation after invalidation.

Question 78

Mini-drill: how to reduce request storms.

Answer 78

Debounce inputs, use staleTime, disable refetch on focus if not needed, narrow invalidations, and dedupe in-flight queries.

Question 79

Mini-drill: reviewer wording for validation.

Answer 79

FAIL - API response is assumed to match expected shape. Validate at the boundary (schema) and handle invalid responses as errors.

Question 80

Mini-drill: reviewer wording for retry policy.

Answer 80

PARTIAL - Retry policy is unsafe for non-idempotent mutations. Disable retries or ensure idempotency; keep retries for safe GETs.