React Code Review: Checklist + AI Tools (2026)

React code review is the review of pull requests in React applications with a focus on interface behavior, state, hooks, rendering, accessibility, security, and integration with the rest of the codebase. The goal is not just to find JavaScript errors, but to understand whether the change keeps the screen predictable when data changes, effects run, components re-render, and users interact with the application.

This type of review tends to get slow because many React bugs do not show up as syntax errors. A pull request can look correct in the diff and still hide a race condition, a performance regression, a hydration issue in Next.js, or a permission validation done only on the client side.

That is why a good process combines human review, tests, linters, and AI code review tools. Automation should handle repetitive patterns, such as suspicious use of useEffect, dangerouslySetInnerHTML without sanitization, overly broad "use client", or missing loading and error states. Human attention stays focused on architecture decisions, product behavior, and business rules.

What changes in a React code review?

React is a JavaScript library for building interfaces with components. The definition is simple, but review starts getting more complicated as the application grows. The person reviewing needs to understand what renders, when it renders, who controls the state, which effects run, and where that code executes: on the server or on the client.

That is why reviewing React is not just validating JavaScript. The problem may be in an incomplete dependency array, in a Context.Provider that is too broad, in an unstable key, or in a component that mixes business rules, data fetching, and visual state.

React 19 also changed part of what shows up in PRs. Actions, useActionState, useOptimistic, use, Server Components, and better hydration messages affect forms, optimistic UI, async data, and the boundaries between server and client. The official React 19 page is a good reference for these points.

React code review checklist

Before bringing in automation, it helps to have a clear baseline for a complete manual review. This checklist organizes the main areas where React applications usually break down.

Components

• Single responsibility: does each component have a clear purpose? Large components with too many responsibilities are hard to test and reuse.
• Props: are prop names clear? Avoid props like data or item. Prefer names that describe the content, such as userProfile or product.
• Logic in JSX: is there too much business logic inside the render block? Complex conditionals and calculations should go into helper functions or hooks to keep JSX declarative.
• Extraction opportunities: could smaller, reusable components be extracted from a larger component? Look for repeated JSX structures.
• Duplication: is there duplicated logic between similar components? This is usually a sign that a shared hook or component is needed.

Hooks

• Unnecessary useEffect: is useEffect being used for something that could be derived from state or props during render? Many effects can be replaced with simpler logic.
• Dependency arrays: are the dependency arrays for useEffect, useCallback, and useMemo correct? Missing dependencies lead to stale closures and bugs. Extra dependencies cause unnecessary re-renders.
• Stale closures: are functions inside useEffect capturing old state or prop values because of incorrect dependencies? This is a common source of subtle bugs.
• Custom hooks: do custom hooks follow the Rules of Hooks and have a clear, single purpose? They should encapsulate a reusable piece of stateful logic.
• Derived state: is there state being stored that could be calculated on the fly? Storing derived state (const [fullName, setFullName] = useState(firstName + ' ' + lastName)) can cause sync bugs. It is usually better to calculate it during render.

State management

• Local vs. global state: is the line between local component state (useState) and shared global state (Context, Redux, etc.) clear? Lifting state should be an intentional decision.
• Context re-renders: is a value that changes frequently being provided through Context, causing large parts of the component tree to re-render? Context works better for low-frequency updates, such as theme or authentication status.
• Separating UI state and remote state: is server cache state from tools like React Query or SWR being mixed with local UI state? Keeping them separate simplifies the logic.
• Single source of truth: for each piece of data, is there a single source of truth or are there multiple copies that can fall out of sync?

Performance

• List keys: do lists have stable and unique keys? Using the array index as a key can cause rendering bugs and performance issues when the list order changes.
• Avoidable re-renders: are components re-rendering when their props and state have not changed? React.memo can help, but the root cause is often unstable object or function references passed as props.
• Memoization: are useMemo and useCallback being used correctly? They should be applied to solve a specific, measured performance problem, not used everywhere. Over-memoization adds complexity and also has a cost.
• Heavy components in loops: are computationally expensive components being rendered inside a loop with map() without memoization?
• Lazy loading: in a large application, are routes or large, non-critical UI sections being loaded on demand with React.lazy to improve initial page load time?

Accessibility (a11y)

• Semantic HTML: are buttons used for actions and links for navigation? Using the correct semantic element is the foundation of accessibility.
• ARIA attributes: when building custom components like dropdowns or modals, are the correct ARIA roles and attributes being used to communicate state to screen readers?
• Focus management: do interactive elements like modals trap focus correctly? Can users navigate through the component using only the keyboard in a logical order?
• Forms: do all form inputs have accessible labels? Are error messages associated with their corresponding inputs?
• Keyboard navigation: does the entire application work as expected using only the Tab, Enter, and Space keys?

Security

• dangerouslySetInnerHTML: avoid using this property. If you need to use it to render HTML from a CMS, make sure the content is sanitized with a library like DOMPurify to prevent XSS attacks.
• Untrusted data: treat all data from APIs or user inputs as untrusted. Sanitize it before rendering.
• Client-side secrets: never put API keys or other secrets in client-side code. They will be publicly visible.
• Backend authorization: client-side permission checks are for UI convenience. All sensitive actions need to be validated again on the backend.
• Open redirects: when handling client-side navigation based on URL parameters, validate the URL to avoid open redirect vulnerabilities.

Which AI code review tools are good for React?

The market for AI code review tools is growing. Although many offer general code analysis, some are better for the specific problems found in React.

Here are 3 tools you can consider:

Kodus

Kodus is an open source AI code review tool focused on pull requests. The main agent, Kody, reviews changes at the file and PR level, comments on specific snippets, and applies rules defined by the team.

The most interesting point for React teams is that Kodus lets the team turn internal decisions into review rules. This changes the usefulness of AI quite a bit. Instead of receiving a generic comment about useEffect, the team can teach what that codebase considers a real risk.

For example:

Block PRs that render HTML from a CMS, markdown, or external API with dangerouslySetInnerHTML without explicit sanitization.

In Next.js App Router applications, mark as high risk any change that adds "use client" to entire pages, layouts, or components that import heavy modules without a clear need.

In authentication, billing, or permissions flows, flag any validation done only in the React component without a corresponding backend check.

These rules can consider the diff, PR metadata, files from the repository itself, and even functions via MCP. For React, this makes a difference because a large part of review depends on local convention and the criticality of the changed area. A simple internal screen may accept a tradeoff that a checkout page, authentication page, or admin panel should not accept.

Kodus also learns from feedback. When the team accepts, rejects, or reacts to suggestions, Kody uses these signals to adjust the next reviews. This is useful because React has many choices that are not universally right or wrong. What matters is consistency inside that codebase.

Another relevant point is BYOK. The team uses its own LLM provider key, chooses the model, and tracks cost directly in the provider. For teams that care about budget, privacy, or dependence on a single model, this control changes the conversation. You can use your API key from providers such as OpenAI, Anthropic, Google Gemini, OpenRouter, Novita, and OpenAI-compatible endpoints.

In a React team with a larger codebase, I see Kodus working best when there are already technical decisions that repeat in review: where external HTML can be rendered, when “use client” is acceptable, how permissions need to be validated, which components require full accessibility, and which changes should block merge.

CodeRabbit

CodeRabbit is an AI code review tool built for pull requests. It comments on changes, generates summaries, helps review diffs, and connects to platforms like GitHub, GitLab, Azure DevOps, and Bitbucket.

For a React team, CodeRabbit can help with common problems: suspicious effects, missing error handling, changes that are too large, possible security issues, and snippets that are hard to review manually. It can also be a good choice when the team wants to put AI review into the flow without creating many rules at the beginning.

The care point here is understanding how much control the team needs. If the codebase has specific decisions around App Router, Server Components, React Query, design system, accessibility, and permissions, it makes sense to test whether the tool follows those standards consistently. For general feedback in PRs, CodeRabbit can work well. For teams that want more control over model, cost, and internal rules, Kodus is the better option for this type of operation.

Graphite Reviewer

Graphite Reviewer is part of a broader platform for PR workflows. The product covers stacked PRs, review inbox, merge queue, automations, and AI Reviews. Because of that, it solves a slightly different problem.

For a React team, Graphite can help when the bottleneck is less about the individual comment and more about review operations. PRs get stuck, diffs depend on each other, the merge queue becomes friction, and it is not always clear what needs to be reviewed first.

In this scenario, AI review is only one part of the system. Graphite helps organize how changes move through the team. It can comment on React PRs, of course, but the differentiator is more in the engineering routine than in specific rules about hooks, hydration, Context, or use client.

Kodus, Coderabbit, Graphite comparison

Criterion	Kodus	CodeRabbit	Graphite Reviewer
Best React use case	Teams that want to review codebase-specific standards: hooks, App Router, permissions, security, accessibility, and architecture rules.	Teams that want to get started quickly with AI review in PRs, automatic summaries, and general comments on the diff.	Teams that need to better organize PR flow, stacked diffs, review queue, and merge queue.
Custom rules	Kody Rules in natural language, with rules at the file or PR level, pull request variables, file references, and MCP.	YAML configuration, path-based instructions, custom checks, and knowledge base.	AI Review customization in paid plans, with automations, filters, and rules.
Repository context	Uses semantic analysis, repository search, rules, memories, team feedback, and reference files.	Uses PR context, knowledge base, linked repository analysis, and repository/organization settings.	More connected to the PR flow: stacked diffs, inbox, merge queue, review history, and automations.
Pricing	BYOK: the team pays tokens directly to the provider, with no token markup. Teams at US$10 per active dev/month + token spend, according to the BYOK page.	Free for summarization. Pro at US$24 user/month annually. Pro Plus at US$48 user/month annually. Enterprise by contact.	Free Hobby with limited AI Reviews. Starter at US$20 user/month annually. Team at US$40 user/month annually. Enterprise by contact.
When to choose	When the team wants AI review close to the codebase’s technical decisions, with open source, BYOK, model choice, and well-defined internal rules.	When the team wants fast adoption and a ready-to-use experience for reviewing PRs without configuring much at the beginning.	When the main pain is review coordination, stacked PRs, merge queue, and engineering workflow organization.