Claude Code for Production React Development: Components, Hooks, Tests, and Review

Claude Code can make React teams faster, but speed alone is not the goal. The real win is turning ambiguous UI work into small, reviewable, tested changes. If you let it generate unlimited components without boundaries, you usually get more files, more props, and less confidence.

This guide shows a production-minded workflow for React + TypeScript: component boundaries, props, state, custom hooks, forms, data fetching, Testing Library tests, accessibility, performance, and review prompts. Keep the official React docs, React Testing Library docs, MDN ARIA guide, and Claude Code docs open while adapting the examples.

For related ClaudeCodeLab material, pair this with TypeScript tips, testing strategies, accessibility implementation, and performance optimization.

What Claude Code Should Own

In React work, Claude Code is strongest when it reads the existing repository, follows local patterns, edits a focused area, and leaves verification evidence. Do not start with “build a beautiful dashboard.” Start with a contract.

Contract item	Example	Why it matters
UI responsibility	List users, filter by role, toggle active state	Prevents a single oversized component
State location	Parent state, URL state, custom hook, server cache	Stops random useState sprawl
Data shape	User, API response, empty state	Makes props and tests concrete
Verification	npm test, npm run build, keyboard checks	Gives reviewers proof

Plain terms help the model and the team. Props are inputs passed from parent to child. State is what the UI remembers. A custom hook is a reusable function for stateful logic. Accessibility means the UI remains usable with a keyboard, screen reader, zoom, and other assistive tools.

Real Use Cases

Use case one is an internal admin list: users, invoices, support tickets, roles, or products. Claude Code can split the page into filters, table, row actions, empty state, and error state while keeping API contracts unchanged.

Use case two is a form workflow: profile editing, contact forms, checkout details, or training signups. Ask Claude Code to preserve labels, validation copy, disabled states, and retry behavior. For deeper form patterns, see React Hook Form with Claude Code.

Use case three is a data fetching screen: search results, notifications, dashboards, and activity feeds. Server state should not be mixed with temporary UI state. If your project uses TanStack Query, continue with the TanStack Query guide; for small client state, compare Zustand state management.

Use case four is review. Instead of asking Claude Code to create more UI, ask it to inspect a diff for unclear component boundaries, unnecessary effects, missing labels, brittle tests, and avoidable re-renders.

Component Boundary Diagram

Use a simple diagram before generating files. This prevents the common failure mode where every text node becomes a separate component.

UserAdminPage
  -> UserFilters: search and role filter
  -> UserTable: table, sort labels, row actions
  -> UserStatusBadge: status display only
  -> UserEditDialog: edit form
  -> useUsers: fetch, refresh, error state

The boundary rule is simple: if you cannot explain a component’s props in one sentence, it is probably doing too much. If a component exists only once and has no independent behavior, it may not need to be extracted yet.

Typed React Component

This component is copy-paste runnable in a Vite React TypeScript project. It does not fetch data. It displays users and sends events upward, which makes it easy to test and easy for Claude Code to modify safely.

import type { FormEvent } from "react";

export type UserRole = "admin" | "editor" | "viewer";

export type User = {
  id: string;
  name: string;
  email: string;
  role: UserRole;
  active: boolean;
};

type UserTableProps = {
  users: User[];
  selectedRole: "all" | UserRole;
  onRoleChange: (role: "all" | UserRole) => void;
  onToggleActive: (id: string) => void;
};

export function UserTable({
  users,
  selectedRole,
  onRoleChange,
  onToggleActive,
}: UserTableProps) {
  const filteredUsers =
    selectedRole === "all"
      ? users
      : users.filter((user) => user.role === selectedRole);

  function handleRoleSubmit(event: FormEvent<HTMLFormElement>) {
    event.preventDefault();
    const formData = new FormData(event.currentTarget);
    onRoleChange(formData.get("role") as "all" | UserRole);
  }

  return (
    <section aria-labelledby="user-table-title">
      <h2 id="user-table-title">Team members</h2>
      <form onSubmit={handleRoleSubmit} style={{ marginBottom: 12 }}>
        <label htmlFor="role">Filter by role </label>
        <select id="role" name="role" defaultValue={selectedRole}>
          <option value="all">All</option>
          <option value="admin">Admin</option>
          <option value="editor">Editor</option>
          <option value="viewer">Viewer</option>
        </select>
        <button type="submit">Apply</button>
      </form>

      {filteredUsers.length === 0 ? (
        <p role="status">No users match this filter.</p>
      ) : (
        <table>
          <thead>
            <tr>
              <th scope="col">Name</th>
              <th scope="col">Email</th>
              <th scope="col">Role</th>
              <th scope="col">Status</th>
              <th scope="col">Action</th>
            </tr>
          </thead>
          <tbody>
            {filteredUsers.map((user) => (
              <tr key={user.id}>
                <td>{user.name}</td>
                <td>{user.email}</td>
                <td>{user.role}</td>
                <td>{user.active ? "Active" : "Paused"}</td>
                <td>
                  <button type="button" onClick={() => onToggleActive(user.id)}>
                    {user.active ? "Pause" : "Activate"}
                  </button>
                </td>
              </tr>
            ))}
          </tbody>
        </table>
      )}
    </section>
  );
}

Custom Hook for Data Fetching

Use hooks to move data and side-effect logic out of presentational components. This example aborts stale requests and avoids state updates after unmount.

import { useEffect, useState } from "react";
import type { User } from "./UserTable";

type UsersState =
  | { status: "loading"; users: User[]; error: null }
  | { status: "success"; users: User[]; error: null }
  | { status: "error"; users: User[]; error: string };

export function useUsers(endpoint: string) {
  const [state, setState] = useState<UsersState>({
    status: "loading",
    users: [],
    error: null,
  });

  useEffect(() => {
    const controller = new AbortController();

    async function loadUsers() {
      setState({ status: "loading", users: [], error: null });

      try {
        const response = await fetch(endpoint, { signal: controller.signal });
        if (!response.ok) throw new Error(`HTTP ${response.status}`);
        const users = (await response.json()) as User[];
        setState({ status: "success", users, error: null });
      } catch (error) {
        if (error instanceof DOMException && error.name === "AbortError") return;
        setState({
          status: "error",
          users: [],
          error: error instanceof Error ? error.message : "Unknown error",
        });
      }
    }

    void loadUsers();
    return () => controller.abort();
  }, [endpoint]);

  return state;
}

In a production app you may use TanStack Query, Relay, SWR, or framework loaders. The same boundary still applies: presentation components should not know more about fetching than they need to.

Testing Library Test

Ask Claude Code to write tests that use labels, roles, and visible text. Avoid snapshot-only tests for interactive components.

import { render, screen } from "@testing-library/react";
import userEvent from "@testing-library/user-event";
import { describe, expect, it, vi } from "vitest";
import { UserTable, type User } from "./UserTable";

const users: User[] = [
  { id: "1", name: "Masa", email: "masa@example.com", role: "admin", active: true },
  { id: "2", name: "Aiko", email: "aiko@example.com", role: "viewer", active: false },
];

describe("UserTable", () => {
  it("filters users and toggles active status", async () => {
    const user = userEvent.setup();
    const onRoleChange = vi.fn();
    const onToggleActive = vi.fn();

    render(
      <UserTable
        users={users}
        selectedRole="all"
        onRoleChange={onRoleChange}
        onToggleActive={onToggleActive}
      />,
    );

    await user.selectOptions(screen.getByLabelText(/filter by role/i), "viewer");
    await user.click(screen.getByRole("button", { name: /apply/i }));
    await user.click(screen.getByRole("button", { name: /activate/i }));

    expect(screen.getByText("Masa")).toBeInTheDocument();
    expect(screen.getByText("Aiko")).toBeInTheDocument();
    expect(onRoleChange).toHaveBeenCalledWith("viewer");
    expect(onToggleActive).toHaveBeenCalledWith("2");
  });
});

Review Prompt for Claude Code

Review this React + TypeScript diff.

Check:
- Component boundaries and whether any component does too much
- Props that could be simplified or grouped
- Unnecessary useEffect usage
- Mixed UI state and server state
- Form labels, error messages, keyboard behavior, and status updates
- Testing Library coverage from the user's perspective
- Avoidable re-renders for large lists

Constraints:
- Do not add new libraries unless you only propose them
- Prefer the smallest useful diff
- End with commands I should run, including npm test and npm run build

Pitfalls to Avoid

The first pitfall is over-generated components. UserNameText, UserEmailText, and UserRoleText rarely help unless they own behavior or are reused. Extraction should improve reuse, state isolation, or testing.

The second pitfall is unnecessary effects. Derived values such as filtered arrays and display labels can usually be computed during render. Ask Claude Code to explain why an effect is needed before it adds one.

The third pitfall is weak accessibility. Placeholder-only inputs, color-only error states, missing table headers, and icon buttons without names are common AI-generated mistakes.

The fourth pitfall is performance theater. Adding memo and useMemo everywhere can make code harder to read. Start with stable keys, local state placement, pagination or virtualization for large lists, and measured changes.

CTA and Result Note

For a solo project, the examples above are enough to start. For a team, put component rules, test commands, accessibility checks, and forbidden over-generation patterns into CLAUDE.md. ClaudeCodeLab offers Claude Code training and consultation for teams that want to apply this workflow to an existing React repository, including UI review, Testing Library, performance receipts, and conversion-focused forms or CTAs.

Hands-on result: using this workflow on a content-site admin UI reduced later prop cleanup because the first prompt fixed boundaries, state ownership, and test expectations before code generation. The most reliable pattern was not “generate more UI”; it was “generate a small diff and prove it works.”