How to review a React pull request

Checklist 9 min read Updated August 2026

A good React review is fast, kind, and consistent. Use this checklist to catch the issues that actually cause bugs — and skip the bikeshedding. Share it with your team so everyone reviews to the same bar.

Correctness & intent

  • Does the change match the PR description and the ticket it closes?
  • Are loading, empty, and error states handled, not just the happy path?
  • Are edge cases covered — no data, one item, very long lists, slow networks?
  • Is dead code, debug logging, and commented-out code removed?

Hooks & effects

  • Are effect dependency arrays correct — no missing or stale values?
  • Does every effect clean up subscriptions, timers, and listeners?
  • Is useMemo/useCallback used where it matters, not sprinkled everywhere?
  • Are the rules of hooks respected — no conditional or nested hooks?
// flag this in review: effect uses `userId` but doesn't depend on it
useEffect(() => {
  fetchUser(userId)
}, [])                 // ← stale: should be [userId]

State & data

  • Is derived data computed, not stored in state and kept in sync manually?
  • Is state colocated — as local as it can be, lifted only when shared?
  • Are list keys stable and unique — never the array index for dynamic lists?
  • Is server state cached rather than refetched on every render/mount?
Practice this
Sharpen your React eye
Review and refactor real React code in a full browser IDE — the same patterns you'll see in PRs.
Practice React

Performance

  • No new object/function literals passed to memoized children each render.
  • Large lists virtualized or paginated, not fully rendered.
  • Heavy components code-split or lazy-loaded where sensible.

Accessibility

  • Interactive elements are real controls (button, a) with accessible names.
  • Inputs have labels; images have alt; focus order is sane.
  • Keyboard and screen-reader paths work, not just mouse.

Readability & tests

  • Names describe intent; components do one thing; props are typed.
  • Tests cover the new behavior and meaningful edge cases.
  • CI is green — lint, type-check, and tests all pass.

Review checklist

  • Behavior matches the PR; loading/empty/error states handled
  • Effect deps correct, cleanups present, hook rules followed
  • Derived data computed, state colocated, stable list keys
  • No wasted re-renders; large lists virtualized
  • Accessible controls, labels, and keyboard support
  • Clear names, typed props, passing tests and CI

FAQ

What should I look for first in a React code review?

Correctness and intent — does the change do what the PR says, and does the UI hold up across loading, empty, and error states. Style and micro-optimizations come after you're confident the behavior is right.

What are the most common React review issues?

Missing or wrong effect dependencies, using the array index as a key, state that should be derived instead of stored, unhandled loading/error states, and missing accessibility on interactive elements.

How do I keep React reviews consistent across a team?

Share a checklist like this one, keep PRs small, and automate what you can — linting, type-checking, and tests in CI — so reviews focus on logic and design rather than formatting.

Put it into practice

Solve real challenges in a full browser IDE — graded automatically.

Browse frameworks