The React Code Review Checklist Engineers Actually Use

A generic code review checklist misses the bugs that actually break React apps: stale closures in useEffect, re-renders triggered by a new object literal passed as a prop, state updates that silently batch wrong. If your team reviews React pull requests with the same checklist you'd use for a Python script, you're catching style issues and missing the failure modes that cause production incidents. A proper react code review checklist has to be built around React's specific execution model — the render cycle, the hooks rules, and the DOM diffing that makes "it works on my machine" not the same as "it works in production."

This article is a working react code review checklist you can paste into your PR template today, organized by the categories where React bugs actually cluster: component structure, hooks and state, rendering performance, accessibility, type safety, and security. Each section includes the specific thing to look for in a diff, not just a reminder to "check for bugs."

This matters whether you're a staff engineer reviewing a dozen PRs a week or a solo founder merging your own code without a second reviewer. The categories below work the same way as a self-review pass before you open a PR — the goal isn't bureaucracy, it's catching the bug before it ships instead of after a customer reports it. Treat this as a living document: delete items your linter already enforces, and add items specific to the bugs your team has actually shipped.

Why React Needs Its Own Code Review Checklist

React's component model introduces failure modes that don't exist in most backend code: unintentional re-renders, effects that run more often than the author expects, and state updates that depend on timing rather than explicit sequencing. A junior reviewer glancing at a diff full of JSX will usually catch typos and obviously wrong logic, but will miss a useEffect with a missing dependency that only manifests three renders later. That's the gap a dedicated react code review checklist closes — it gives reviewers specific, repeatable things to check instead of relying on each person's accumulated intuition.

The cost of skipping this is measurable in bug reports, not just vibes. Teams that track code quality metrics for pull requests typically find that rendering and state bugs are among the most expensive to diagnose post-merge, because they're intermittent and hard to reproduce locally — see our breakdown of code quality metrics for pull requests and the cost of technical debt for how to quantify this on your own repo. A checklist applied consistently at review time is cheaper than a bug ticket, a reproduction session, and a hotfix three weeks later.

Consider a concrete example: a missing dependency in a useEffect that fetches user data causes the component to show stale information after a prop changes. In review, this is a two-minute fix — add the dependency, re-test. In production, it surfaces as a confusing support ticket ("my profile shows old data sometimes"), takes an engineer half a day to reproduce because it's intermittent, and often gets misdiagnosed as a caching issue before anyone looks at the effect's dependency array. The gap between those two costs is the entire argument for a react code review checklist.

There's also a consistency argument. When five different engineers review React PRs with five different mental models of "what good looks like," your codebase drifts — some components use useMemo defensively, others never do; some effects have explicit cleanup, others leak listeners. A shared react code review checklist, enforced the same way on every PR regardless of who's reviewing, is what keeps a growing team's React code looking like it was written by one disciplined engineer instead of a committee. This is the same logic behind enforcing standards with AI in the age of LLM-generated code — consistency has to be mechanical, not aspirational.

Component Design and Structure Checks

Before looking at logic, check the shape of the component itself. A component review pass should answer: is this component doing one thing, is its prop interface sane, and is state owned at the right level.

Concrete items to check on every PR:

• Prop drilling depth — if a prop is passed through more than two intermediate components untouched, flag it for context or composition instead.
• Component size — a function component over roughly 150–200 lines, excluding JSX markup, is a signal it's doing too much and should be split.
• Conditional rendering clarity — nested ternaries beyond one level should become early returns or extracted sub-components.
• Key props on lists — array index used as key on a list that can reorder or filter is a correctness bug waiting to happen, not a style nit.
• Default props and optional chaining — new optional props should have explicit defaults or guarded access, not implicit undefined handling scattered through the render body.

A concrete example worth internalizing: a UserCard component that accepts user, theme, onEdit, onDelete, isAdmin, showAvatar, and compactMode as props is already past the point where a reviewer should ask whether theme and compactMode belong in a shared DisplayOptions object instead of seven flat props. It's a small thing in one PR, but across fifty components it's the difference between a prop interface a new hire can read in thirty seconds and one that requires scrolling through the whole file to understand what's actually required.

Component structure issues are easy to defer because they "work" — the app renders fine with a 300-line component and index-based keys, right up until someone reorders the list or adds a ninth level of nesting. That's exactly why they belong on a written react code review checklist rather than left to reviewer memory: the bug they cause shows up weeks later, far from the PR that introduced it. If your team is also dealing with inconsistent patterns across a growing codebase, our guide on reducing pull request review time covers how tighter structural conventions shrink review cycles too.

Hooks and State Management: The Core of the Checklist

This is where most real React bugs live, and where a react code review checklist earns its keep. Hooks rules are mechanically checkable, but violations are easy to miss in a quick visual scan of a diff.

Walk through every hook touched in the PR with these questions:

1. Does the useEffect dependency array match what's actually read inside the effect? Missing dependencies cause stale closures; the eslint-plugin-react-hooks exhaustive-deps rule catches most of these automatically — if it's not enabled in CI, that's a bigger finding than anything in the PR itself.
2. Is state being derived that should just be computed during render? A useState + useEffect combo that only copies a prop into state is almost always wrong — it should be a plain derived value or a useMemo.
3. Are state updates batched the way the author expects? Multiple setState calls inside an async callback behave differently depending on React version and context; check that the author tested the actual update sequence, not just the final value.
4. Is a custom hook doing too much? If a custom hook returns more than four or five values, it's probably two hooks wearing a trench coat.
5. Are refs used to bypass the render cycle for a reason that should instead be state? A ref holding a value that should trigger a re-render when it changes is a common review catch.

A realistic example: useEffect(() => { setFilteredItems(items.filter(i => i.category === selectedCategory)); }, [items]) compiles cleanly and passes a casual read, but it's missing selectedCategory in the dependency array — the filtered list silently goes stale the moment a user changes the category filter without the items array also changing. This is the exact class of bug that eslint-plugin-react-hooks's exhaustive-deps rule flags automatically, and it's also the single most common comment reviewers leave on React PRs once they start looking for it deliberately.

Reviewers who internalize this table rarely need to ask "did you test this?" in a review comment — the dependency array and derived-state checks surface the answer directly in the diff.

Rendering Performance Items Worth Flagging

Not every PR needs a performance audit, but certain patterns are cheap to catch in review and expensive to fix later. A react code review checklist should include a short, targeted performance pass rather than a blanket "optimize everything" mandate — premature memoization adds complexity without benefit.

Flag these specifically:

• New object or array literals passed as props to memoized child components — <Child options={{ sort: true }} /> defeats React.memo every render because the object reference changes each time.
• Inline function definitions passed to deeply nested children in large lists — fine for a handful of items, a real cost in a 500-row table.
• Missing virtualization on lists rendering more than a few hundred DOM nodes; point the author at react-window or similar rather than asking them to "just optimize it."
• Context providers wrapping large subtrees with values that change frequently — every consumer re-renders on every change, even ones that only read one field.
• Effects that fetch data on every render because a dependency was derived incorrectly, rather than fetching once on mount or on a specific trigger.

The React team's own guidance on render and commit phases is worth linking in your internal review docs — it gives non-performance-specialist reviewers the mental model to understand why an object literal prop matters. Most performance regressions caught in review aren't exotic; they're the same five patterns above showing up in a new file.

Accessibility Checks That Belong in Every PR

Accessibility is the category most React teams skip in review, and it's the one most likely to produce a legal or support cost down the line, not just a technical debt ticket. A react code review checklist that stops at logic and rendering but ignores markup semantics is only half a checklist for a UI codebase.

Minimum items to check on any PR touching JSX:

• Interactive elements use semantic tags — a div with an onClick handler and no role or keyboard handler is not accessible; it should be a button or have the ARIA attributes and keyboard handling to match.
• Form inputs have associated labels, either via htmlFor/id pairing or aria-label, not just placeholder text standing in for a label.
• Images and icons convey meaning through alt text or aria-hidden, not left with empty or missing alt attributes.
• Focus management on modals and dialogs — opening a modal should move focus into it, and closing it should return focus to the trigger element.
• Color is never the only signal for state (error, success, disabled) — check for an icon or text accompanying color changes.

Automated tooling catches roughly half of accessibility issues — contrast ratios, missing labels, invalid ARIA attributes — and tools like axe-core or eslint-plugin-jsx-a11y can run in CI to catch them before a human reviewer even opens the diff. The other half, like whether a screen reader announces a dynamic state change in a sensible order, genuinely needs a person to tab through the component or run it with VoiceOver or NVDA at least once before merge, especially for anything shipping as a new interactive pattern rather than a reused design-system component.

The WCAG 2.2 guidelines and web.dev's accessibility fundamentals are the two references worth bookmarking for your team's review docs. None of these checks require a dedicated accessibility engineer — they're pattern-matching a reviewer can do in under a minute once it's part of the habitual react code review checklist rather than an occasional audit.

Type Safety Checks for TypeScript React Projects

Most production React code is TypeScript now, and type safety issues slip through review more often than you'd expect because tsc passing gives a false sense of security — types can be technically correct and still loose enough to hide bugs.

Checklist items specific to typed React components:

• Props interfaces avoid any and overly broad unions. A prop typed as data: any defeats the entire point of the type system; push for a specific interface or generic.
• Event handler types match the actual element. onChange: (e: any) => void on an <input> should be React.ChangeEvent<HTMLInputElement>.
• Discriminated unions for component state, not optional fields that can be in invalid combinations (e.g., loading: true and data: SomeType both populated simultaneously).
• Generic components actually use their generics, rather than accepting any and casting internally.
• Return types on custom hooks are explicit tuples or objects, not inferred in a way that breaks when the hook's internals change.

Enabling strict: true alone isn't the whole story — noUncheckedIndexedAccess and exactOptionalPropertyTypes catch a different class of bug than basic strict mode, specifically around array access returning undefined and optional props being set to undefined explicitly versus omitted. Turning these on for the first time in an established codebase usually surfaces a batch of pre-existing type gaps; treat that as a one-time cleanup PR rather than blocking every future PR on fixing decade-old type debt all at once.

For a deeper pass on this category specifically, our TypeScript code review best practices guide covers the broader patterns beyond React components — narrowing, generics, and strict mode configuration that a react code review checklist should assume is already enforced at the compiler level before a human even opens the diff.

Security Items Specific to React Applications

React's JSX escaping handles most XSS risk automatically, which is exactly why the remaining risks get missed — reviewers assume React "handles it" and stop checking. A react code review checklist needs explicit security items because the gaps are narrow but real.

Check for these on any PR touching user-generated content or external data:

• dangerouslySetInnerHTML usage — every instance should be justified in a PR comment and the content sanitized with a library like DOMPurify, not trusted raw HTML.
• URLs rendered in href or src attributes from user input — unvalidated javascript: URLs are a classic bypass of React's default escaping.
• Environment variables exposed to the client — anything prefixed for client-side bundling (NEXT_PUBLIC_, VITE_, REACT_APP_) should never contain secrets, since it ships in the JS bundle.
• Third-party script and widget embeds added via useEffect DOM manipulation, which bypasses React's rendering model and its safety guarantees entirely.
• Dependency updates for UI libraries — a new date picker or rich text editor dependency is also a new attack surface; check it against known CVEs before merge.

This category overlaps with the general discipline covered in AI code review for security vulnerabilities beyond static analysis — static analysis tools catch the dangerouslySetInnerHTML pattern reliably, but judgment calls about sanitization completeness still need a human or a model reasoning about context, which is exactly the gap multi-model review tools are built to close.

Testing and CI Gates to Pair With the Checklist

A checklist is only as good as the gate that enforces it. Pairing your react code review checklist with CI checks means reviewers spend their attention on the judgment calls — architecture, naming, edge cases — instead of re-verifying things a linter already confirmed.

Minimum CI setup to support a React code review checklist:

1. ESLint with eslint-plugin-react-hooks and eslint-plugin-jsx-a11y running on every PR, blocking merge on errors (not just warnings).
2. TypeScript strict mode (strict: true in tsconfig.json) as a required check, not an aspirational setting someone turns on "later."
3. Component tests with React Testing Library for any component with conditional rendering logic — snapshot tests alone don't catch behavioral regressions.
4. Bundle size tracking on PRs that touch dependencies, since a new UI library can silently add hundreds of kilobytes.
5. Visual regression testing (Chromatic, Percy, or similar) for design-system components, since this is the one category a text-based checklist genuinely cannot cover.

If your branch protection rules aren't currently requiring these checks before merge, that's a higher-leverage fix than refining the checklist wording — see our guide on GitHub branch protection for the specific settings to require status checks and block direct pushes to main. A checklist that reviewers can bypass under deadline pressure isn't a gate, it's a suggestion.

Automating the React Code Review Checklist

Manually running a 25-item checklist on every PR doesn't scale past a handful of engineers — people skip steps under time pressure, and skipped steps are invisible until the bug ships. This is the practical argument for automating as much of a react code review checklist as possible, reserving human attention for the architecture and product judgment calls that tooling can't make.

Static analysis (ESLint, TypeScript) covers the mechanically checkable half: hook dependency arrays, any usage, unused variables. What it doesn't cover is context — whether a derived state pattern makes sense for this specific feature, whether the accessibility fix actually matches the design intent, whether a new useEffect is solving the right problem. That's the gap AI-assisted review tools target, running multiple models against a diff to catch the hooks and rendering issues above alongside the logic bugs a linter can't see.

CodeMouse applies this approach to GitHub PRs specifically — reviewing every pull request with Claude, GPT, and Gemini and posting inline comments mapped to the same categories in this checklist, at a flat monthly price instead of a per-seat license. You can see the specific workflow on how it works or compare the approach against other tools in our AI code review comparison.

The right mental model is layered: linter rules enforce the checklist items that are purely mechanical, an AI reviewer catches the items that need context but not deep product knowledge, and a human reviewer spends their limited time on the architecture decisions and edge cases that actually need a person. Teams that split it this way report shorter review cycles without lowering their bar — see our broader guide on how to reduce code review cycle time for the numbers behind that claim and how to measure it on your own repo.

Putting the Checklist Into Your PR Template

The checklist only works if it's somewhere a reviewer actually looks during review, not buried in a wiki page nobody opens. The lowest-friction place to put it is your GitHub pull request template, as a checkbox list the author fills out before requesting review and the reviewer re-verifies.

A trimmed version that fits in a PR template without becoming its own essay:

• [ ] Hook dependency arrays reviewed for completeness
• [ ] No new object/array literals passed to memoized components
• [ ] Interactive elements are keyboard-accessible
• [ ] No any types introduced on new props or handlers
• [ ] No dangerouslySetInnerHTML without sanitization
• [ ] List keys are stable, not array indices on reorderable lists
• [ ] Component tests added or updated for new conditional logic

Some teams go further and require the author to link evidence next to riskier checkboxes — a screenshot of the DevTools Profiler for the performance item, a short screen recording of keyboard navigation for the accessibility item. This adds a minute or two to PR prep but turns a checkbox from an honor-system claim into something the reviewer can actually verify in fifteen seconds instead of re-doing the work themselves.

For the general structure of a PR template beyond React-specific items, our GitHub pull request checklist covers the broader fields worth including — linked issues, rollback plan, deployment notes. Combining that general template with this react code review checklist gives you one document that covers both process and React-specific technical risk, which is the combination that actually gets used instead of ignored.

Measuring Whether Your React Code Review Checklist Is Working

A checklist nobody tracks is just a hope. Once it's rolled out, you need a feedback loop that tells you whether it's changing outcomes, not just adding friction to every PR. The simplest signal is a tally: for every production bug traced back to a merged PR, ask which checklist item — if any — would have caught it, and whether that item was actually checked at review time.

Concrete things to track over a rolling 90-day window:

• Escaped defect rate by category — of the bugs that reach production, how many fall into hooks/state, rendering, accessibility, type safety, or security? This tells you which checklist section needs reinforcement.
• Checklist completion rate — if your PR template has checkboxes, how often are they actually checked versus skipped under deadline pressure?
• Time from PR open to first substantive review comment — a checklist that's too long slows reviewers down; a well-scoped one speeds them up by removing ambiguity about what to look for.
• Review comment reuse — the same comment ("missing dependency in useEffect") showing up repeatedly across unrelated PRs is a sign the item belongs in CI as a lint rule, not in a human-reviewed checklist.

If a category keeps producing escaped defects despite being on the checklist, that's usually not a checklist problem — it's a signal the check needs to move from "ask a human to remember it" to "enforce it mechanically." Our guide on code review metrics that matter covers the broader set of numbers worth tracking beyond React-specific categories, including cycle time and defect escape rate, and how to set up a lightweight dashboard without building custom tooling.

Closing Thoughts

A react code review checklist is only valuable if it changes what reviewers actually look at, not just what they say they check. Start small: pick the five items from this list most relevant to your last three production bugs, put them in your PR template this week, and track whether review comments start catching those patterns before merge instead of after.

Expand from there as your team's specific failure modes become clear — every codebase has a slightly different shape of bug, and the checklist should reflect yours, not just a generic list copied from a blog post. If you want a second set of eyes applying this checklist automatically on every PR, CodeMouse's multi-model review runs these exact categories against your diffs — details on pricing if you want to see where it fits against the cost of the bugs you're currently shipping without it.