klen/react-useeffect-avoid

React: When Not to Use useEffect

Core Principle

useEffect is an escape hatch for synchronizing with external systems, not a general-purpose tool for state management or event handling.

Modern React patterns prioritize one-way data flow and event-driven updates over effect-based synchronization to avoid performance penalties and complex synchronization bugs.

---

When NOT to Use useEffect

1. ❌ Calculating Derived State

Problem: Computing one state value from another using useEffect causes unnecessary double-renders and complexity.

// ❌ BAD: Double render cycle
function FilteredList({ items }) {
  const [query, setQuery] = useState('');
  const [filtered, setFiltered] = useState([]);

  useEffect(() => {
    setFiltered(items.filter(item => item.name.includes(query)));
  }, [items, query]); // Renders twice on every input

  return <ul>{filtered.map(item => <li key={item.id}>{item.name}</li>)}</ul>;
}

✅ Solution: Calculate derived state directly during render.

// ✅ GOOD: Single render, no effect needed
function FilteredList({ items }) {
  const [query, setQuery] = useState('');

  // Calculated every render - no state, no effect
  const filtered = items.filter(item => item.name.includes(query));

  return <ul>{filtered.map(item => <li key={item.id}>{item.name}</li>)}</ul>;
}

Why it's better:

• Immediate feedback UI updates (no double render pause)
• Simpler mental model: what you see is what you get
• No dependency array to manage
• React can optimize calculations via memoization when needed

---

2. ❌ Resetting State When a Prop Changes

Problem: Watching a prop change and manually resetting state causes stale data display and extra renders.

// ❌ BAD: Shows old state briefly, then new
function UserForm({ userId }) {
  const [userName, setUserName] = useState('');
  const [email, setEmail] = useState('');

  useEffect(() => {
    setUserName('');  // First render shows old userName
    setEmail('');    // Then this effect runs to reset
  }, [userId]);      // Double render every userId change

  return (
    <form>
      <input value={userName} onChange={e => setUserName(e.target.value)} />
      <input value={email} onChange={e => setEmail(e.target.value)} />
    </form>
  );
}

✅ Solution A: Key Prop (Preferred)

// ✅ GOOD: React tears down and rebuilds component
function App() {
  const [userId, setUserId] = useState(1);

  return (
    <div>
      <button onClick={() => setUserId(prev => prev + 1)}>Next User</button>
      {/* Different key = different component instance */}
      <UserForm key={userId} userId={userId} />
    </div>
  );
}

✅ Solution B: Derived State (When you only need partial reset)

// ✅ GOOD: Only reset specific values, keep others
function UserForm({ userId }) {
  const [userName, setUserName] = useSyncExternalStore(
    () => ({ onSet: setUserName }), // Reset when userId changes
    { value: '' }
  );
  const [email, setEmail] = useState('');

  // Email persists, userName resets
  return <form>...</form>;
}

⚠️ Caveat: The key prop approach remounts the entire component. Use when you need a complete state reset. For partial resets, consider derived state patterns.

---

3. ❌ Waterfall of State Updates

Problem: Multiple effects triggering each other create cascading renders that are hard to debug.

// ❌ BAD: Effects trigger effects
function OrderForm() {
  const [formData, setFormData] = useState({});
  const [validated, setValidated] = useState(false);
  const [error, setError] = useState(null);

  // Effect 1: Validate when formData changes
  useEffect(() => {
    setValidated(validateData(formData));
  }, [formData]);

  // Effect 2: Set error when validation changes
  useEffect(() => {
    setError(validated ? null : 'Invalid');
  }, [validated]);

  // Effect 3: Submit when no error
  useEffect(() => {
    if (!error && validated) submitOrder(formData);
  }, [error, validated, formData]);
}

✅ Solution: Handle all logic in event handler.

// ✅ GOOD: One handler, one render, clear flow
function OrderForm() {
  const [formData, setFormData] = useState({});

  const handleSubmit = () => {
    // All logic happens atomically
    if (validateData(formData)) {
      submitOrder(formData);  // No intermediate states
    } else {
      setError('Invalid form');  // Set directly, no cascade
    }
  };

  return <button onClick={handleSubmit}>Submit</button>;
}

---

4. ❌ Fetching Data on User Action

Problem: Using a flag to trigger effects loses user intent and creates fragile code.

// ❌ BAD: Intent is lost, hard to follow
function LoginForm() {
  const [username, setUsername] = useState('');
  const [submitted, setSubmitted] = useState(false);

  const handleSubmit = () => {
    setSubmitted(true);  // Just a flag, no actual logic
  };

  useEffect(() => {
    if (submitted) {
      login(username);  // What triggered this? Which submit was it?
    }
  }, [submitted, username]);
}

✅ Solution: Perform action directly in handler.

// ✅ GOOD: Clear intent, direct action
function LoginForm() {
  const [username, setUsername] = useState('');

  const handleSubmit = async (e) => {
    e.preventDefault();  // User action context preserved

    // Actual logic here, not delayed
    try {
      await login(username);
    } catch (error) {
      console.error('Login failed:', error);
    }
  };

  return <form onSubmit={handleSubmit}>...</form>;
}

---

5. ❌ Filtering/Transforming Lists

Problem: Creating filtered lists via effects is a common mistake that causes extra renders.

// ❌ BAD: Unnecessary effect
function ProductList({ products }) {
  const [visibleProducts, setVisibleProducts] = useState([]);

  useEffect(() => {
    setVisibleProducts(products.filter(p => p.inStock));
  }, [products]); // Runs twice whenever products change
}

✅ Solution: Filter directly during render.

// ✅ GOOD: Immediate, single render
function ProductList({ products }) {
  const visibleProducts = products.filter(p => p.inStock);
}

---

6. ❌ Subscribing to Browser APIs (Without useSyncExternalStore)

Problem: Using useState + useEffect for external subscriptions causes "tearing" in concurrent rendering.

// ❌ BAD: UI can show inconsistent state during concurrent updates
function WindowSize() {
  const [width, setWidth] = useState(window.innerWidth);

  useEffect(() => {
    const handleResize = () => setWidth(window.innerWidth);
    window.addEventListener('resize', handleResize);
    return () => window.removeEventListener('resize', handleResize);
  }, []);
}

✅ Solution: Use useSyncExternalStore for external state.

// ✅ GOOD: Prevents tearing, single source of truth
function WindowSize() {
  const width = useSyncExternalStore(
    // Subscribe - return cleanup function
    (callback) => {
      window.addEventListener('resize', callback);
      return () => window.removeEventListener('resize', callback);
    },
    // Get snapshot
    () => window.innerWidth,
    // Server fallback
    () => 1200
  );
}

Why it's better:

• React can guarantee UI consistency even during concurrent rendering
• Single source of truth
• Built-in optimization - subscription fires only when needed

---

7. ❌ Initial Data Fetch Without Dependencies (Stale Data)

Problem: Empty dependency array with state inside effect causes stale bugs.

// ❌ BAD: Id never updates, always fetches user 1
function UserProfile({ userId }) {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetch(`/user/1`).then(res => res.json()).then(setUser);
  }, [ ]); // Missing userId dependency!
}

✅ Solution: Include all dependencies or use proper patterns.

// ✅ GOOD: Correct dependencies
function UserProfile({ userId }) {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetch(`/user/${userId}`).then(res => res.json()).then(setUser);
  }, [userId]); // Properly tracks changes
}

Better: Move to event-driven fetching or data libraries.

// ✅ EVEN BETTER: No effect, just loader
function UserProfile({ userId }) {
  const user = use(userId); // React 19's use API
  // Or use React Query, SWR, etc.
}

---

Decision Tree: useEffect vs Alternatives

Need to sync with external system?
├─ Yes (browser APIs, websockets, timers)
│  └─ Use useEffect
│
└─ No (pure React application logic)
   ├─ Derived state calculation?
   │  ├─ Yes → Calculate during render
   │  └─ No → Continue...
   │
   ├─ User action triggered?
   │  ├─ Yes → Use event handler
   │  └─ No → Continue...
   │
   ├─ State reset needed?
   │  ├─ Yes → Use key prop
   │  └─ No → Continue...
   │
   └─ Really need effect after re-think?
      └─ Yes → Use useState/useReducer/setState pattern

---

Patterns to Always Avoid

❌ 1. useEffect for DOM Manipulation (without refs)

// BAD
function Modal() {
  useEffect(() => {
    document.body.style.overflow = 'hidden';
    return () => { document.body.style.overflow = ''; };
  }, []);
}

✅ Better: Use refs or layout effects when needed.

---

❌ 2. useEffect for Logging

// BAD
function App({ data }) {
  useEffect(() => {
    console.log('Data changed:', data);
  }, [data]);
}

✅ Better: Log in event handler or use React DevTools profiling.

---

❌ 3. useEffect for Component Initialization

// BAD
function Widget() {
  const [initialized, setInitialized] = useState(false);

  useEffect(() => {
    someLibrary.init();
    setInitialized(true);
  }, []);
}

✅ Better: Initialize outside component effect:

// GOOD
let initialized = false;

function Widget() {
  if (!initialized) {
    someLibrary.init();
    initialized = true;
  }
}

Or use library-specific initialization patterns.

---

Quick Reference

❌ Don't use useEffect for

| Scenario | Problem | Alternative | |----------|---------|-------------| | Derived state | Double render | Calculate during render | | State resets | Stale data | Use key prop | | User actions | Lost intent | Event handlers | | List filtering | Extra renders | Filter in render | | Browser APIs | Tearing bugs (concurrent) | useSyncExternalStore | | Form submission | Fragile flag pattern | Direct async handler | | Data fetching | Manual cache management | React Query, SWR, Suspense |

✅ DO use useEffect for

• Subscribing to external systems (websockets, browser APIs, etc.)
• Setting up timers with cleanup
• Managing third-party library integration
• Document title changes
• Analytics/telemetry when rendering completes

---

React 19: New Alternatives

React 19 introduces the use API for reading resources in render:

// React 19+ - Direct resource reading
function UserProfile({ userId }) {
  const user = use(fetchUser(userId)); // Reads promise directly

  return <div>{user.name}</div>;
}

This eliminates many data-fetching useEffect patterns entirely.

---

References and Further Reading

Official Documentation

• React Docs: You Might Not Need an Effect
• React Docs: Synchronizing with Effects
• React Docs: useSyncExternalStore

Articles from Senior Engineers

• LogRocket: 15 Common useEffect Mistakes
  • Comprehensive anti-pattern catalog
• Epic React: Myths About useEffect - Kent Dodds on mental models
• Kent Dodds: useSyncExternalStore Demystified

Key Principles

1. Effects are escape hatches - use only when stepping outside React
2. Event-driven > Effect-driven - prefer handlers for user actions
3. Render-time > Effect-time - calculate values during render
4. Single source of truth - avoid duplicating state in effects
5. Concurrent-safe - use specialized hooks for external subscriptions