React Code Design Review

React Code Design Review

Review React code structure without turning team preferences into universal rules.

Operating contract

• Treat review as read-only unless the user also asks for fixes.
• Inspect the target component, its call sites, relevant hooks, tests, and nearby conventions.
• Distinguish page, feature, design-system, and reusable leaf components; the right ownership differs by role.
• Report only findings with a concrete maintenance, correctness, accessibility, or change-locality cost.
• Prefer the smallest change that restores a clear owner. Do not reward extraction by itself.

1. Establish context

Before judging structure, resolve:

1. platform and rendering model: React web, React Native, server rendering, client rendering, or a mixture;
2. component role and reuse surface;
3. who owns data loading, mutations, state, spacing, error handling, and accessibility;
4. actual call sites and whether the suspected coupling already creates repeated change;
5. repository rules and established component patterns.

If the evidence is unavailable, mark the point as unverified instead of inventing a design problem.

2. Apply only relevant rules

Read references/rules.md and select only rules supported by the target code. The rule groups are:

• locality and ownership;
• UI-to-code mapping and responsibility;
• data access and side effects;
• composition and external layout;
• naming and pure logic;
• semantics and accessibility.

Rules are heuristics with exceptions. A server component may intentionally own loading for its subtree. A design-system component may intentionally own layout tokens. A small callback may be clearer as handleSubmit than a long procedural name.

3. Admit findings narrowly

A finding must contain all four elements:

1. Location: exact file and symbol or tight line range.
2. Evidence: current call flow, duplicated decision, leaked state, inaccessible interaction, or repeated change cost.
3. Consequence: what becomes harder to understand, test, reuse, or change.
4. Smallest correction: the minimum ownership or structure change that resolves the evidence.

Reject findings based only on:

• component length;
• hypothetical future reuse;
• personal folder or naming preference;
• a single prop passed one level;
• extraction that merely moves code;
• a rule whose stated exception matches the current design.

4. Prioritize

• High: correctness, inaccessible interaction, hidden cross-component state, or a structure already causing inconsistent behavior.
• Medium: concrete repeated change cost, unclear ownership, or coupling across established seams.
• Low: worthwhile cleanup with local evidence but no current behavioral risk.

Do not assign a severity when the claim is only a question or needs missing runtime evidence.

5. Report

Return:

## React code design review

### Findings
1. [High|Medium|Low] Short title
   - Location: `path:line`
   - Evidence: current code and call-site evidence
   - Consequence: concrete cost or risk
   - Smallest correction: bounded change

### Good boundaries to preserve
- Existing ownership or composition decisions that should not be disturbed

### Unverified
- Missing call-site, runtime, accessibility, or repository evidence

### Verdict
`CLEAN` or `CHANGES_RECOMMENDED`

If fixes are authorized, change only admitted findings, run focused checks, and report what each check actually proves.