Writing React Effects Skill

Guides writing React components that avoid unnecessary useEffect calls.

Core Principle

Effects are an escape hatch for synchronizing with external systems (network, DOM, third-party widgets). If there's no external system, you don't need an Effect.

Decision Flowchart

When you see or write useEffect, ask:

Is this synchronizing with an EXTERNAL system?
├─ YES → useEffect is appropriate
│   Examples: WebSocket, browser API subscription, third-party library
│
└─ NO → Don't use useEffect. Use alternatives:
    │
    ├─ Transforming data for render?
    │   → Calculate during render (inline or useMemo)
    │
    ├─ Handling user event?
    │   → Move logic to event handler
    │
    ├─ Expensive calculation?
    │   → useMemo (not useEffect + setState)
    │
    ├─ Resetting ALL state when prop changes?
    │   → Pass different `key` to component
    │
    ├─ Adjusting SOME state when prop changes?
    │   → Calculate during render or rethink data model
    │
    ├─ Subscribing to external store?
    │   → useSyncExternalStore
    │
    └─ Fetching data?
        → Framework data fetching or custom hook with cleanup

Anti-Patterns to Detect and Fix

When useEffect IS Appropriate

• Syncing with external systems (WebSocket connections, third-party widgets, browser APIs)
• Setting up and cleaning up subscriptions
• Fetching data based on current props (always include cleanup to handle race conditions)
• Measuring or imperatively mutating DOM elements after render
• Integrating with non-React code (jQuery plugins, analytics SDKs, etc.)

Common Refactoring Patterns

Derived state → compute during render

tsx
1// ❌ Bad
2const [filtered, setFiltered] = useState([]);
3useEffect(() => {
4  setFiltered(items.filter((i) => i.active));
5}, [items]);
6
7// ✅ Good
8const filtered = items.filter((i) => i.active);
9// or with useMemo for expensive operations
10const filtered = useMemo(() => items.filter((i) => i.active), [items]);

Notify parent → call in event handler

tsx
1// ❌ Bad
2useEffect(() => {
3  onSelect(selectedId);
4}, [selectedId]);
5
6// ✅ Good
7function handleClick(id) {
8  setSelectedId(id);
9  onSelect(id);
10}

Reset state on prop change → key prop

tsx
1// ❌ Bad
2useEffect(() => {
3  setComment("");
4}, [userId]);
5
6// ✅ Good — key remounts the component, resetting all state
7<ProfileForm key={userId} userId={userId} />;

Data fetching → custom hook with cleanup

tsx
1// ❌ Bad — no cleanup, race conditions possible
2useEffect(() => {
3  fetch(`/api/user/${id}`)
4    .then((r) => r.json())
5    .then(setUser);
6}, [id]);
7
8// ✅ Good — cleanup prevents stale responses
9useEffect(() => {
10  let cancelled = false;
11  fetch(`/api/user/${id}`)
12    .then((r) => r.json())
13    .then((data) => {
14      if (!cancelled) setUser(data);
15    });
16  return () => {
17    cancelled = true;
18  };
19}, [id]);
20
21// ✅ Even better — use a data-fetching library (React Query, SWR, TanStack Query)
22const { data: user } = useQuery({
23  queryKey: ["user", id],
24  queryFn: () => fetchUser(id),
25});

Instructions for Claude

When this skill is invoked:

1. Identify every useEffect call in the provided code
2. Apply the decision flowchart to each effect individually
3. Flag anti-patterns from the table above with a clear explanation of the problem
4. Provide refactored code using the appropriate alternative for each case
5. Leave legitimate effects untouched — only remove effects that don't belong
6. When writing new components, never reach for useEffect unless the flowchart confirms it's appropriate

Prioritize correctness over cleverness. A derived value computed inline is always clearer than an effect that syncs it into state.