Frontend Component Review

The Problem

Frontend components start simple and grow into tangled masses. A “simple” card component accumulates 15 props, 3 useState hooks, 2 useEffect side effects, and inline styles. Props drill through 4 levels of nesting because “context felt like overkill.” Every keystroke in a search input re-renders 200 list items because the filter function is recreated every render. The component tree becomes so intertwined that changing one component breaks three others.

The Prompt

Review the following frontend components. Act as a frontend architect evaluating for scalability, performance, and clean composition.

FRAMEWORK: [React / Vue / Svelte / Astro]
COMPONENT TYPE: [e.g., form, data table, navigation, dashboard widget]

CODE:
[paste your component code here]

Evaluate across these dimensions:

1. **Component Responsibility**
   - Does each component do one thing (display OR logic, not both)?
   - Are components under 150 lines?
   - Should this be split into a container (logic) + presentational (UI) pair?
   - Are there components doing fetch + transform + render in one file?

2. **Props & API**
   - Is the prop interface clean (under 7 props)?
   - Are props drilling through 3+ levels (should use context/store)?
   - Are callback props stable (wrapped in useCallback)?
   - Are default props sensible? Are required props truly required?

3. **State Management**
   - Is state as close as possible to where it is used?
   - Is derived state computed (useMemo) rather than synced via useEffect?
   - Are there redundant state variables that can be derived from others?
   - Is form state managed efficiently (not re-rendering on every keystroke)?

4. **Rendering Performance**
   - Are list items wrapped in React.memo (or Vue key)?
   - Are expensive computations memoized?
   - Do useEffect dependencies include unstable references (objects, arrays)?
   - Are conditional renders avoiding unnecessary DOM mutations?

5. **Side Effects**
   - Do useEffects have proper cleanup functions?
   - Are side effects grouped by concern (not multiple unrelated effects)?
   - Are fetch calls deduplicated (useSWR/React Query vs raw useEffect)?
   - Is there a loading/error/empty state for async data?

6. **Composition**
   - Is the component tree flat or deeply nested?
   - Are slots/children/render props used for flexible composition?
   - Can this component be reused in a different context without modification?

For each issue, provide:
- **Component**: Name and file
- **Severity**: rewrite (fundamentally flawed) / refactor / optimization / style
- **Problem**: Why this hurts scalability or performance
- **Fix**: Refactored code

Example Output

## Frontend Component Review: 5 issues found

### Refactor: Prop Drilling Through 4 Levels
Component: App → Layout → Sidebar → NavItem (user prop)
Fix: Use React context:
  const UserContext = createContext<User | null>(null);
  // In App: <UserContext value={user}>
  // In NavItem: const user = useContext(UserContext);

### Optimization: List Re-renders on Every Keystroke
Component: SearchResults.tsx
Code: results.filter(r => r.name.includes(query)) runs on every render.
Fix:
  const filtered = useMemo(
    () => results.filter(r => r.name.includes(query)),
    [results, query]
  );
  // Plus: wrap list items in React.memo

### Refactor: useEffect Syncing Derived State
Code:
  const [fullName, setFullName] = useState('');
  useEffect(() => setFullName(first + ' ' + last), [first, last]);
Fix: Derive directly:
  const fullName = `${first} ${last}`;  // No state, no effect needed

When to Use

Run this when reviewing component PRs, when a page feels sluggish, or when a component has grown beyond 200 lines. Essential during design system construction where component APIs must be clean enough for team-wide adoption. Use it to catch the React anti-patterns that work in prototypes but collapse in production.

Pro Tips

• Include the component tree — many issues live in the relationship between components, not inside a single one. Describe or paste the parent-child hierarchy.
• Profile before memoizing — use React DevTools Profiler to identify actual re-render bottlenecks rather than memoizing everything preemptively.
• Ask for a decomposition plan — for large components, follow up with “Break this into atomic design layers: atoms, molecules, organisms.”