/meta-reviewing-web-reviewing

name: meta-reviewing-web-reviewing
description: UI component review patterns. Use when reviewing React components, hooks, props, state, styling, and accessibility. Covers rules of hooks, effect cleanup, render performance, list keys, keyboard and ARIA patterns.

Web Code Review Patterns

> **Quick Guide:** When a diff touches UI components, verify hooks obey the rules of hooks with complete dependency arrays, effects clean up what they set up, list keys are stable, and interactive elements the diff adds are reachable by keyboard with accessible names. Judge performance concerns against evidence in the diff, not against a memoize-everything ideal.

---

<critical_requirements>

CRITICAL: Before Reviewing Web Code

> **All code must follow project conventions in CLAUDE.md** (kebab-case, named exports, import ordering, `import type`, named constants)

**(You MUST verify hooks are called unconditionally at top level, with dependency arrays that name every value the callback reads)**

**(You MUST verify every effect that subscribes, registers a listener, or starts a timer returns a cleanup function)**

**(You MUST check every interactive element the diff adds for keyboard reachability and an accessible name)**

**(You MUST verify list keys are stable identities, not array indexes on lists that can reorder)**

**(You MUST check memoization against evidence: flag a missing memo only for a demonstrable cost in the diff, and flag speculative memo/useCallback wrapping as churn)**

</critical_requirements>

---

**Auto-detection:** review component, React PR review, hooks review, JSX diff, component code review, accessibility review, a11y check, re-render review

**When to use:**

• Reviewing diffs containing React components (`.tsx`/`.jsx` with JSX)
• Reviewing custom hooks, effects, or state management inside components
• Checking accessibility of new or changed interactive UI
• Evaluating render-performance claims or concerns in a diff
• Reviewing controlled form inputs and event handling

**When NOT to use:**

• When implementing components (use the relevant web implementation skill)
• For server routes, configs, or build tooling in the same diff (use the API/infra reviewing skills)
• For visual design judgments a spec does not define

**Key patterns covered:**

• Rules of hooks and dependency-array completeness
• Effect cleanup for subscriptions, listeners, and timers
• Props and state typing
• Evidence-based render performance review
• List keys and reconciliation
• Controlled components and event handling
• Accessibility for diff-added interactive elements

**Detailed Resources:**

• [examples/core.md](examples/core.md) - Good/bad component patterns to look for during review

---

<philosophy>

Philosophy

**Review the component the diff builds, not the component you would have built.** React offers many valid shapes for the same UI; flag deviations from the codebase's established patterns and genuine defects, not alternatives.

**When reviewing web code:**

• Trace each hook's dependency array against what its callback actually reads
• Trace each effect to its cleanup - what it starts, something must stop
• Walk the keyboard path through any UI the diff adds: can you reach it, operate it, and see focus?
• Treat state as the source of truth: derived values should be computed, not mirrored into more state

**When NOT to flag:**

• Don't demand `React.memo`, `useMemo`, or `useCallback` without a demonstrable cost in the diff - speculative memoization is churn that obscures the data flow
• Don't demand component extraction for a component that is long but linear
• Don't flag inline styles or styling choices that follow the file's existing approach
• Don't request accessibility work on elements the diff did not touch

**Core principles:**

• **Correctness first**: stale closures and missing cleanup are bugs, not style
• **Accessibility is scoped to the diff**: everything added must be operable; everything untouched is not this review's job
• **Evidence over ideal**: performance feedback cites a cost the diff creates
• **State minimalism**: the fewer sources of truth, the fewer ways to disagree

</philosophy>

---

<patterns>

Core Patterns

Pattern 1: Rules of Hooks and Dependency Arrays

Hooks must be unconditional and their dependency arrays complete.

## Hooks Review

For EACH hook call in the diff:

- [ ] Called at top level - not inside conditionals, loops, or early-return paths
- [ ] Dependency array names every prop, state value, and function the callback reads
- [ ] No dependency silenced with an eslint-disable that lacks a justifying comment
- [ ] Functions used as dependencies are stable (defined outside, or wrapped where identity matters)

// Must Fix: stale closure - `filter` is read but not declared
useEffect(() => {
  fetchItems(filter).then(setItems);
}, []); // runs once, forever using the first render's filter

// Good: complete dependencies
useEffect(() => {
  fetchItems(filter).then(setItems);
}, [filter]);

**Why this matters:** An incomplete dependency array pins the callback to stale values. The bug is invisible until the value changes, then the UI silently shows old data.

---

Pattern 2: Effect Cleanup

What an effect starts, its cleanup must stop.

## Effect Cleanup Review

For EACH effect the diff adds or changes:

- [ ] Subscriptions are unsubscribed in the returned cleanup
- [ ] Event listeners added to window/document are removed
- [ ] Timers (setTimeout/setInterval) are cleared
- [ ] In-flight async work is guarded (AbortController or a cancelled flag) before setState

// Must Fix: listener leaks on every unmount/remount
useEffect(() => {
  window.addEventListener("resize", onResize);
}, [onResize]);

// Good: symmetric cleanup
useEffect(() => {
  window.addEventListener("resize", onResize);
  return () => window.removeEventListener("resize", onResize);
}, [onResize]);

**