Data — Cheat Sheet

Fetching Data — And Why It Is Harder Than It Looks

function useProblems(topic) {
  const [state, setState] = useState({ status: 'loading' })

  useEffect(() => {
    const controller = new AbortController()
    setState({ status: 'loading' })

    fetch(`/api/problems?topic=${encodeURIComponent(topic)}`, {
      signal: controller.signal,
    })
      .then(res => {
        if (!res.ok) throw new ApiError(res.status)   // fetch does NOT reject on 4xx
        return res.json()
      })
      .then(data => setState({ status: 'success', data }))
      .catch(err => {
        if (err.name === 'AbortError') return         // superseded, not a failure
        setState({ status: 'error', error: err })
      })

    return () => controller.abort()
  }, [topic])

  return state
}

// That is the minimum for ONE endpoint. Now add: retry, caching
// across components, refetch on window focus, invalidation after a
// mutation, and pagination.

Designing the Loading, Error and Empty States

// A skeleton reserves the final layout, so nothing jumps when data lands
function ProblemsSkeleton() {
  return (
    <ul aria-busy="true" aria-label="Loading problems">
      {Array.from({ length: 6 }, (_, i) => (
        <li key={i} className="h-16 rounded animate-pulse bg-muted" />
      ))}
    </ul>
  )
}

// A spinner in the middle of an empty page tells the user nothing
// about what is arriving, and guarantees a layout shift.

// Avoid the flash: if the response takes 80ms, showing a skeleton
// for 80ms looks like a glitch. Delay it.
const showSkeleton = useDelayedFlag(isLoading, 200)

// Distinguish first load from a background refresh:
//   isLoading    -> no data yet, show the skeleton
//   isFetching   -> data on screen, show a subtle indicator instead
{isFetching && <span className="text-xs">Updating…</span>}

TanStack Query — Queries, Keys and Caching

const { data, isLoading, isFetching, isError, error, refetch } = useQuery({
  queryKey: ['problems', { topic, page }],
  queryFn: ({ signal }) => listProblems({ topic, page, signal }),
  staleTime: 60_000,        // treat as fresh for a minute
})

if (isLoading) return <ProblemsSkeleton />
if (isError)   return <ErrorState error={error} onRetry={refetch} />
return <ProblemList problems={data} />

// What you no longer write: the loading flag, the error state, the
// abort controller, the race guard, the mount check, and the
// deduplication when three components ask for the same thing.

// The key IS the cache identity. Anything the queryFn depends on
// must be in it, or you will show one topic's data under another.
queryKey: ['problems', { topic, page }]     // correct
queryKey: ['problems']                      // wrong — topic ignored

// Changing the key is how you refetch: no manual trigger needed.

Mutations and Optimistic Updates

const queryClient = useQueryClient()

const submit = useMutation({
  mutationFn: (payload) => submitSolution(problemId, payload),
  onSuccess: (result) => {
    queryClient.invalidateQueries({ queryKey: ['submissions', problemId] })
    queryClient.invalidateQueries({ queryKey: ['progress'] })
    toast.success('Submitted')
  },
  onError: (err) => toast.error(describe(err)),
})

<button onClick={() => submit.mutate({ code })} disabled={submit.isPending}>
  {submit.isPending ? 'Running…' : 'Submit'}
</button>

// isPending is the disabled state you were tracking by hand, and it
// is what stops a double-click creating two submissions.

// The discipline: after every write, list what is now stale.
// A stale sidebar counter is the classic missed invalidation.

Pagination, Infinite Scroll and Search

const { data, isPlaceholderData } = useQuery({
  queryKey: ['problems', { topic, page }],
  queryFn: () => listProblems({ topic, page }),
  placeholderData: keepPreviousData,      // hold the old page during the fetch
})

<ProblemList problems={data.items} dimmed={isPlaceholderData} />
<Pagination
  page={page}
  total={data.totalPages}
  onChange={setPage}
  disabled={isPlaceholderData}
/>

// Without keepPreviousData the list unmounts on every page change
// and the page jumps to a skeleton — the classic flicker.

// Put the page in the URL, not in state, so back/forward and a
// shared link both work:
const [params, setParams] = useSearchParams()
const page = Number(params.get('page') ?? 1)

// And always reset to page 1 when a filter changes, or the user
// lands on an out-of-range page with no results.

Cache Behaviour — Staleness, Refetching and Invalidation

// Structure keys from general to specific
['problems']                                  // everything problems-related
['problems', 'list', { topic, page }]         // one list
['problems', 'detail', slug]                  // one item

// Then invalidation can be as broad or narrow as the write requires
queryClient.invalidateQueries({ queryKey: ['problems'] })            // all
queryClient.invalidateQueries({ queryKey: ['problems', 'list'] })    // lists only
queryClient.invalidateQueries({ queryKey: ['problems', 'detail', slug] })

// A key factory keeps them consistent and typo-proof
export const problemKeys = {
  all: ['problems'],
  lists: () => [...problemKeys.all, 'list'],
  list: (filters) => [...problemKeys.lists(), filters],
  details: () => [...problemKeys.all, 'detail'],
  detail: (slug) => [...problemKeys.details(), slug],
}

// The bug this prevents: one file uses ['problem', slug] and another
// uses ['problems', slug], so the invalidation silently misses.

Authentication in a React App

// Option A — httpOnly cookie set by the server (the stronger default)
//   + JavaScript cannot read it, so an XSS cannot steal it
//   - needs SameSite and CSRF protection
//   - needs credentials: 'include' for cross-origin calls
fetch('/api/me', { credentials: 'include' })

// Option B — access token in memory, refresh token in an httpOnly cookie
//   + works cleanly across separate API domains and mobile clients
//   + the access token is never persisted, so a reload drops it
//   - more moving parts

// Anti-pattern: the token in localStorage. Any script on the page can
// read it, so one XSS — including one inside a dependency — hands over
// every session.

// And never decode a JWT on the client and trust it for authorisation.
// Read it for display (a name, an expiry) only; the server decides
// what the user is allowed to do.

Real-Time Data in React

// A socket per component means N connections and N reconnect loops.
// One provider, near the root, is the shape you want.

function RealtimeProvider({ children }) {
  const queryClient = useQueryClient()

  useEffect(() => {
    const ws = new WebSocket(WS_URL)

    ws.onmessage = (e) => {
      const event = JSON.parse(e.data)
      handle(event, queryClient)
    }
    ws.onclose = (e) => { if (!e.wasClean) scheduleReconnect() }

    return () => ws.close()          // cleanup, always
  }, [queryClient])

  return children
}

// queryClient is stable, so this effect runs once — and because the
// handler writes to the cache rather than to component state, no
// component needs to know the socket exists.

// For one-way updates, prefer SSE: it reconnects by itself and
// needs no heartbeat. See the JavaScript track's streaming concept.