React Component Reviewer

Overview

This skill provides a systematic approach to reviewing React components, identifying issues, and suggesting improvements across multiple dimensions: best practices, hooks usage, performance, accessibility, and TypeScript type safety.

Prerequisites

• The React component code to review
• Understanding of the component's purpose and context
• Knowledge of the project's React version and conventions

Review Checklist

1. React Best Practices

• Component naming follows PascalCase convention
• Props are properly typed (TypeScript interfaces/types)
• Component has a single, clear responsibility
• Avoid unnecessary wrapper divs (use fragments)
• Event handlers follow naming convention (handle*, on*)
• No inline object/array literals in JSX (causes re-renders)
• Keys are stable and unique for lists (not using index)
• Conditional rendering is clear and readable
• No console.log or debug code left behind

2. Hooks Usage

• Hooks are called at top level (not inside conditions/loops)
• Hooks follow the rules of hooks
• useEffect dependencies are complete and correct
• No missing dependencies (ESLint warnings)
• Cleanup functions in useEffect where needed
• useMemo/useCallback used appropriately (not prematurely)
• Custom hooks follow naming convention (use*)
• useState initial values are properly typed
• useRef usage is correct for DOM refs and mutable values

3. Performance

• No unnecessary re-renders (React.memo where appropriate)
• Expensive calculations wrapped in useMemo
• Event handlers wrapped in useCallback when passed to children
• No premature optimization (only optimize if there's a problem)
• Large lists use virtualization if needed
• Images have proper dimensions and loading strategies
• No N+1 rendering patterns
• Component splits are logical and performance-conscious

4. Accessibility (a11y)

• Semantic HTML elements used (button, nav, main, etc.)
• Interactive elements are keyboard accessible
• ARIA labels present where needed
• Form inputs have associated labels
• Focus management is correct (modals, dynamic content)
• Color contrast meets WCAG standards
• Alt text for images (or empty alt for decorative)
• Headings follow hierarchical order (h1, h2, h3)
• No accessibility violations (test with axe-core)

5. TypeScript Type Safety

• No use of any type (use unknown if truly unknown)
• Props interface is well-defined and exported if needed
• Event handlers have correct types (React.MouseEvent, etc.)
• Generic types used correctly (React.FC vs function components)
• Return types are explicit for complex functions
• Discriminated unions for variant components
• Optional props marked with ?
• ReadonlyArray for props that shouldn't mutate

6. Testing Considerations

• Component is testable (not too many side effects)
• Props are mockable/injectable
• External dependencies can be stubbed
• Component has corresponding test file
• Critical user interactions are covered by tests

7. Code Quality

• DRY principle followed (no repeated logic)
• Magic numbers/strings extracted to constants
• Error handling is present and appropriate
• Loading and error states are handled
• Comments explain "why" not "what"
• Consistent formatting (Prettier)

Review Output Format

Structure your review as follows:

## Component Review: [ComponentName]

### Summary
[1-2 sentence overview of the component and overall code quality]

### Critical Issues 🔴
[Issues that must be fixed - security, accessibility, breaking bugs]

### Performance Issues 🟡
[Performance problems that should be addressed]

### Best Practice Improvements 🔵
[Non-critical improvements for better code quality]

### Positive Highlights ✅
[Things the component does well - always include this!]

### Detailed Findings

#### [Category Name]
**Issue**: [Description with file:line reference]
**Current Code**:
```typescript
// problematic code

Recommendation:

// improved code

Rationale: [Why this change matters]

[Repeat for each finding]

Priority Recommendations

1. [Most important fix]
2. [Second priority]
3. [Third priority]

## Examples

### Example Review

```markdown
## Component Review: UserProfile

### Summary
Well-structured component with good TypeScript usage, but has accessibility issues and unnecessary re-renders.

### Critical Issues 🔴

1. **Missing Keyboard Accessibility** (UserProfile.tsx:45)
   - Custom dropdown not keyboard accessible
   - Add onKeyDown handlers and ARIA attributes

2. **Incorrect Hook Dependencies** (UserProfile.tsx:23)
   - useEffect missing `userId` dependency
   - Can cause stale data issues

### Performance Issues 🟡

1. **Inline Function in JSX** (UserProfile.tsx:67)
   ```typescript
   // Current
   <Button onClick={() => handleClick(userId)}>Click</Button>

   // Better
   const handleButtonClick = useCallback(() => {
     handleClick(userId);
   }, [userId]);

   <Button onClick={handleButtonClick}>Click</Button>

Best Practice Improvements 🔵

1. Props Interface Could Be More Specific (UserProfile.tsx:5)

   • Use discriminated union for status instead of string

2. Magic Number (UserProfile.tsx:89)

   • Extract 100 to named constant MAX_BIO_LENGTH

Positive Highlights ✅

• Excellent TypeScript typing for props and state
• Good separation of concerns with custom hooks
• Proper error boundary implementation
• Clean, readable JSX structure

Priority Recommendations

1. Fix keyboard accessibility (Critical for WCAG compliance)
2. Fix useEffect dependencies (Prevents bugs)
3. Optimize re-renders with useCallback (Performance)

## Guidelines

### When Reviewing
- **Be Specific**: Always reference file names and line numbers
- **Provide Context**: Explain why something is an issue
- **Show Examples**: Include before/after code snippets
- **Be Constructive**: Balance criticism with positive feedback
- **Prioritize**: Not everything needs to be fixed immediately
- **Consider Trade-offs**: Performance optimizations have complexity costs

### What to Prioritize
1. **Critical Issues**: Security, accessibility violations, bugs
2. **Performance**: Only if there's actual evidence of problems
3. **Best Practices**: Code quality and maintainability
4. **Style**: Lowest priority, unless it affects readability

### What NOT to Flag
- Personal style preferences (if project has Prettier/ESLint)
- Premature optimizations without performance data
- Minor naming nitpicks
- Things that are already handled by automated tools

### Code Review Tone
- Professional and respectful
- Educational (explain the "why")
- Actionable (provide clear next steps)
- Balanced (acknowledge good code too)

## Common React Anti-Patterns to Watch For

1. **State Management Issues**
   - Derived state that should be computed
   - State that should be props
   - Multiple setState calls that should be batched

2. **Effect Issues**
   - useEffect that should be event handlers
   - Missing cleanup functions
   - Infinite loops from missing dependencies

3. **Performance**
   - Creating components inside components
   - Inline objects/arrays in JSX
   - Not memoizing context values

4. **TypeScript**
   - Using `any` instead of proper types
   - Not typing event handlers
   - Missing generic constraints

## Testing the Component

After reviewing, consider suggesting:
- Unit tests for logic
- Integration tests for user flows
- Accessibility tests with @testing-library/jest-dom
- Visual regression tests if applicable

## Limitations

This skill focuses on React component code review. It does not:
- Run automated tests (suggest running them separately)
- Check runtime performance (requires profiling)
- Verify design system compliance (requires design specs)
- Test in multiple browsers (requires manual/automated testing)

## Next Steps After Review

1. Create a prioritized list of changes
2. Discuss critical issues with the team
3. Create tickets/issues for non-trivial fixes
4. Consider refactoring if issues are widespread
5. Update team guidelines if patterns emerge