Stop Using useEffect Like This: 5 Patterns That Are Silently Breaking Your React App

I was doing a code review for a colleague when I found it.

The component had five useEffect hooks.

No errors. No warnings in the console. The PM had signed off on it. It had been in production for three months.

But there was a subtle bug that only showed up when the user navigated quickly between pages.

Data would flash. State would reset. Sometimes the old user's name would appear for a split second before updating to the new one.

Three hours later, we traced it back to a single misused useEffect.

That's the thing about this hook: it fails silently, in slow motion, and always at the worst moment.

TL;DR

• useEffect is the most misused hook in React and most bugs that seem "mysterious" trace back to it.
• Five specific patterns are responsible for 90% of the problems: derived state, overloaded effects, stale closures, unstructured fetches, and unnecessary usage.
• React 18's Strict Mode adds a layer of complexity that catches many of these bugs in development, if you know what to look for.

Table of Contents

• Why useEffect Is Deceptively Hard
• Pattern 1: Deriving State Inside useEffect
• Pattern 2: Overloading a Single useEffect
• Pattern 3: Missing or Suppressed Dependencies
• Pattern 4: Fetching Data Without Structure
• Pattern 5: Using useEffect When You Simply Don't Need It
• Bonus: React 18, Strict Mode, and the Double-Mount Trap
• Before vs After: A Real Refactoring
• A Better Mental Model
• Final Thoughts

Why useEffect Is Deceptively Hard

At first glance, useEffect looks simple:

useEffect(() => {
  // do something
}, [])

It feels like: "run this code when something happens."

But the React docs describe it very differently:

useEffect is a hook that lets you synchronize a component with an external system.

That word, synchronize, changes everything.

It's not a lifecycle replacement. It's not an event handler. It's a way to keep your UI in sync with something outside of React.

The moment you treat it as a general-purpose utility, you open the door to every problem we're about to look at.

Pattern 1: Deriving State Inside useEffect

This is the most common mistake, and the one I see even in senior developers' code.

// ❌ Don't do this
const [fullName, setFullName] = useState<string>('')

useEffect(() => {
  setFullName(`${firstName} ${lastName}`)
}, [firstName, lastName])

This looks harmless. It even feels clean.

But here's what actually happens under the hood:

1. Component renders with firstName and lastName.
2. React runs the effect after the render.
3. setFullName triggers another render.
4. The user briefly sees an empty or stale fullName. You've just added an extra render cycle for no reason.

The fix

// ✅ Compute it during render
const fullName = `${firstName} ${lastName}`

That's it. No state. No effect. No extra render. No stale flash.

Rule of thumb: If you can compute a value from existing props or state, never put it in useState. Compute it inline.

The React docs even have a whole section on this called "You might not need an effect", worth bookmarking.

Pattern 2: Overloading a Single useEffect

This one grows gradually. It starts innocent:

// ❌ Three completely unrelated things in one effect
useEffect(() => {
  fetchUser(userId)
  setupWebSocketSubscription()
  document.title = `Dashboard - ${appName}`
}, [userId, appName])

Now imagine this in two months, after three more developers have touched it.

The problem isn't just readability. It's coupling.

If fetchUser starts causing issues, you need to reason about the subscription and the document title at the same time.

If appName changes, your effect re-runs, which means you're also re-fetching the user and re-subscribing unnecessarily.

The fix

One effect, one responsibility:

// ✅ Each effect has a single, clear purpose
useEffect(() => {
  fetchUser(userId)
}, [userId])

useEffect(() => {
  const unsubscribe = setupWebSocketSubscription()
  return () => unsubscribe()
}, [])

useEffect(() => {
  document.title = `Dashboard - ${appName}`
}, [appName])

Notice the cleanup function in the second effect, that's the bonus you get when you split effects: cleanups become obvious and natural.

Pattern 3: Missing or Suppressed Dependencies

We've all done this at least once.

// ❌ The eslint-disable comment is a red flag, not a solution
useEffect(() => {
  processOrder(orderId, userPreferences)
  // eslint-disable-next-line react-hooks/exhaustive-deps
}, [])

The eslint-disable comment is almost always a sign that something in the design needs to change, not that the linter is wrong.

Here's the subtle bug this creates:

// What the developer thinks:
// "This runs once on mount, using the current orderId."

// What actually happens:
// "This captures orderId at mount time and never updates,
//  even if orderId changes while the component is still mounted."

This is called a stale closure. The effect "remembers" the old value of orderId forever.

The fix

// ✅ Be explicit about what the effect depends on
useEffect(() => {
  processOrder(orderId, userPreferences)
}, [orderId, userPreferences])

If adding the dependency causes unwanted re-runs, the real fix is usually one of these:

• Move the value outside the component (if it's static).
• Use useCallback or useMemo to stabilize the reference.
• Reconsider whether the effect is the right tool for the job. Never silence the linter. Fix the design.

Pattern 4: Fetching Data Without Structure

This is the one everyone starts with:

// ❌ Simple, but missing critical pieces
useEffect(() => {
  fetch(`/api/users/${userId}`)
    .then(res => res.json())
    .then(setUser)
}, [userId])

What's wrong with it? Let me count:

• No loading state: the UI hangs silently.
• No error handling: if the request fails, nothing happens.
• No cancellation: if userId changes before the request completes, you get a race condition.
• Not reusable: you'll copy-paste this into ten components. The race condition is the nastiest one. Here's what it looks like:

// ❌ Race condition scenario
// 1. userId changes to "user-2"
// 2. Effect runs, starts fetching "user-2"
// 3. userId changes again to "user-3"
// 4. Effect runs, starts fetching "user-3"
// 5. "user-3" response arrives first
// 6. "user-2" response arrives and overwrites "user-3" data
// 7. You're now showing the wrong user's data

The fix: a custom hook

At minimum, extract the logic and handle cancellation:

// ✅ Custom hook with loading, error, and cleanup
function useUser(userId: string) {
  const [user, setUser] = useState<User | null>(null)
  const [isLoading, setIsLoading] = useState(true)
  const [error, setError] = useState<Error | null>(null)

  useEffect(() => {
    let cancelled = false
    setIsLoading(true)

    fetch(`/api/users/${userId}`)
      .then(res => {
        if (!res.ok) throw new Error('Failed to fetch user')
        return res.json()
      })
      .then(data => {
        if (!cancelled) setUser(data)
      })
      .catch(err => {
        if (!cancelled) setError(err)
      })
      .finally(() => {
        if (!cancelled) setIsLoading(false)
      })

    return () => {
      cancelled = true
    }
  }, [userId])

  return { user, isLoading, error }
}

The cancelled flag is the key: it prevents state updates after the component has moved on.

The fix: use a library (recommended)

For production apps, don't reinvent the wheel. Libraries like TanStack Query (formerly React Query) handle all of this for you, caching, deduplication, background refetching, race conditions, and more.

// ✅ TanStack Query: this replaces ~30 lines of manual code
import { useQuery } from '@tanstack/react-query'

function UserProfile({ userId }: { userId: string }) {
  const { data: user, isLoading, error } = useQuery({
    queryKey: ['user', userId],
    queryFn: () => fetch(`/api/users/${userId}`).then(res => res.json()),
  })

  if (isLoading) return <Spinner />
  if (error) return <ErrorMessage error={error} />

  return <div>{user.fullName}</div>
}

If you're not using TanStack Query yet, it's one of the highest-value libraries you can add to a React project.

TanStack Query

Powerful asynchronous state management, server-state utilities and data fetching. Fetch, cache, update, and wrangle all forms of async data in your TS/JS, React, Vue, Solid, Svelte & Angular applications all without touching any "global state"

tanstack.com

Pattern 5: Using useEffect When You Simply Don't Need It

Sometimes useEffect gets used just because it's the only tool that feels right:

// ❌ This isn't a side effect, it's just logic
useEffect(() => {
  if (items.length === 0) {
    setIsEmpty(true)
  } else {
    setIsEmpty(false)
  }
}, [items])

Or even:

// ❌ This belongs in an event handler, not an effect
useEffect(() => {
  if (formSubmitted) {
    validateAndSave()
  }
}, [formSubmitted])

The second one is a particularly sneaky antipattern. If you're reacting to a user action (a button click, a form submit), use an event handler. Effects are for syncing with external systems, not for responding to user interactions.

The fix

// ✅ Derived value, not state
const isEmpty = items.length === 0

// ✅ Event handler for user interactions
function handleSubmit() {
  setFormSubmitted(true)
  validateAndSave()
}

Ask yourself before writing any useEffect:
"What external system am I syncing with?"

If the answer is "nothing, I'm just reacting to some state", you don't need an effect.

Bonus: React 18, Strict Mode, and the Double-Mount Trap

This section trips up a lot of developers upgrading to React 18.

In development mode, React 18's Strict Mode intentionally mounts your components twice.

This is new. And it's by design.

React is preparing for a future feature (concurrent rendering and resumable state) where components may be mounted, unmounted, and remounted without losing state. To catch bugs early, Strict Mode simulates this in development.

Here's what happens:

Component mounts   → Effect runs
Component unmounts → Cleanup runs
Component mounts   → Effect runs again  ← This is new in React 18

If your effects are written correctly (with proper cleanup), you'll never notice this. If they're not, you'll see strange behaviors:

// ❌ This effect causes a double API call in Strict Mode
useEffect(() => {
  fetch('/api/init')
    .then(res => res.json())
    .then(setData)
}, [])

In development with React 18 Strict Mode, this runs twice. In production, it runs once.

This confuses developers into thinking their code is broken. It's not broken, it's exposing that the code wasn't safe to run twice.

The fix

// ✅ With cleanup, the double-mount is harmless
useEffect(() => {
  let cancelled = false

  fetch('/api/init')
    .then(res => res.json())
    .then(data => {
      if (!cancelled) setData(data)
    })

  return () => {
    cancelled = true
  }
}, [])

Now the second mount runs the effect again, but the cleanup from the first run has already set cancelled = true, so the first fetch's result is ignored.

Key insight: If your effect breaks when it runs twice, it was always broken. Strict Mode is just making it visible.

Before vs After: A Real Refactoring

Let me show you how these patterns compound in a real component.

This is similar to what I found during that code review I mentioned at the start:

// ❌ Before: a component that "works" but has 4 different issues
interface Props {
  userId: string
}

function UserDashboard({ userId }: Props) {
  const [user, setUser] = useState<any>(null)
  const [fullName, setFullName] = useState<string>('')
  const [isAdmin, setIsAdmin] = useState<boolean>(false)

  // Issue 1: Derives state that could be computed inline
  // Issue 2: Mixes fetch logic with transformation
  useEffect(() => {
    fetch(`/api/users/${userId}`)
      .then(res => res.json())
      .then(data => {
        setUser(data)
        setFullName(`${data.firstName} ${data.lastName}`)
        setIsAdmin(data.role === 'admin')
      })
    // Issue 3: Missing userId dependency
    // eslint-disable-next-line react-hooks/exhaustive-deps
  }, [])

  // Issue 4: Effect for something that isn't a side effect
  useEffect(() => {
    if (user) {
      console.log('User loaded:', user.id)
    }
  }, [user])

  return (
    <div>
      <h1>{fullName}</h1>
      {isAdmin && <AdminBadge />}
    </div>
  )
}

Problems:

• fullName and isAdmin are derived state, extra renders for nothing.
• The eslint-disable is hiding a stale closure bug.
• The logging effect is just noise.

- No loading state, no error handling, no cleanup.

// ✅ After: clean, predictable, and reusable

interface User {
  id: string
  firstName: string
  lastName: string
  role: 'admin' | 'user'
}

// Data fetching logic extracted into a custom hook
function useUser(userId: string) {
  const [user, setUser] = useState<User | null>(null)
  const [isLoading, setIsLoading] = useState<boolean>(true)
  const [error, setError] = useState<Error | null>(null)

  useEffect(() => {
    let cancelled = false
    setIsLoading(true)

    fetch(`/api/users/${userId}`)
      .then(res => {
        if (!res.ok) throw new Error('Failed to fetch')
        return res.json() as Promise<User>
      })
      .then(data => {
        if (!cancelled) {
          setUser(data)
          setIsLoading(false)
        }
      })
      .catch(err => {
        if (!cancelled) {
          setError(err)
          setIsLoading(false)
        }
      })

    return () => { cancelled = true }
  }, [userId])

  return { user, isLoading, error }
}

// Component is now clean and purely presentational
function UserDashboard({ userId }: { userId: string }) {
  const { user, isLoading, error } = useUser(userId)

  if (isLoading) return <Spinner />
  if (error) return <p>Something went wrong.</p>
  if (!user) return null

  // Derived values computed inline, no state, no effects
  const fullName = `${user.firstName} ${user.lastName}`
  const isAdmin = user.role === 'admin'

  return (
    <div>
      <h1>{fullName}</h1>
      {isAdmin && <AdminBadge />}
    </div>
  )
}

What changed:

• Zero derived state, fullName and isAdmin are computed inline.
• One effect, one responsibility, and it's properly cleaned up.
• No suppressed linter warnings.
• Loading and error states handled explicitly.
• The component is now easy to test, easy to read, and easy to modify. Same functionality. Dramatically different maintainability.

A Better Mental Model

Here's the shift that changes how you write React:

Old mental model: "When should this code run?"

New mental model: "What external system am I keeping in sync?"

External systems that useEffect is appropriate for:

• APIs and data sources: fetching data from a server.
• Browser APIs: document.title, localStorage, IntersectionObserver.
• Third-party libraries: charts, maps, analytics SDKs that live outside React's tree.
• Subscriptions: WebSockets, event listeners, timers. If none of these describe what you're doing, you probably don't need useEffect.

Before writing one, run through this quick checklist:

• [ ] Can I compute this value during render instead?
• [ ] Is this reacting to a user action? (Use an event handler.)
• [ ] Is this effect doing more than one thing? (Split it.)
• [ ] Do I have a cleanup function? (If not, why not?)
• [ ] Would this break if it ran twice? (If yes, it was already broken.)

Final Thoughts

useEffect isn't bad.

It's one of the most powerful primitives React gives you.

But power without understanding leads to exactly the kind of silent, slow-burn bugs that show up three months after launch, on a Friday afternoon, right before a demo.

The goal isn't to use useEffect correctly.

The goal is to need it less.

Every unnecessary effect you remove is:

• One fewer render cycle.
• One fewer stale closure waiting to happen.
• One fewer thing to explain to the next developer who reads your code. Write less. Compute more. Clean up always.

Which of these five patterns have you fallen into this week? Drop your story in the comments, the more specific, the better. I've shared mine. Now it's your turn.

If this was useful, a ❤️ or a 🦄 unicorn helps more people find it.

And if you want more of this kind of deep-dive into everyday React patterns, follow me here on DEV! I publish weekly.