useEffect Hook — Complete React Interview Guide

What useEffect actually does — the execution model

React renders in two phases:

1. Render phase — React calls your component function, builds a virtual DOM tree, diffs it against the previous one. This must be pure and side-effect-free.
2. Commit phase — React writes changes to the real DOM. After this, effects run.

useEffect runs after the commit phase, asynchronously. The browser has already painted the updated UI before your effect starts. This is intentional — effects should not block the visual update. If you need to run something synchronously before the browser paints (e.g., measuring DOM layout), use useLayoutEffect instead.

// Execution order for a component that renders twice:
// 1. Component renders (render phase)
// 2. React commits to DOM
// 3. Browser paints
// 4. useEffect runs (effect 1)
// --- state update → re-render ---
// 5. Component renders again
// 6. React commits to DOM
// 7. Browser paints
// 8. React runs cleanup from effect 1
// 9. useEffect runs (effect 2)

The three signatures and what each means

// Signature 1: No dependency array — runs after EVERY render
useEffect(() => {
  document.title = `Score: ${score}`
})
// Use when: the effect must always stay in sync with every state change.
// Rarely what you want — causes unnecessary work.
 
// Signature 2: Empty dependency array — runs ONCE after mount
useEffect(() => {
  fetchUserData()
  return () => { /* cleanup on unmount */ }
}, [])
// Use when: set up that only needs to happen once (subscriptions, one-time fetches, analytics).
 
// Signature 3: Dependency array with values — runs when values change
useEffect(() => {
  fetchPosts(userId)
}, [userId])
// Use when: an external system needs to sync with specific state/props.

The dependency array — the most misunderstood part

The dependency array is not an optimisation — it is a declaration of what the effect depends on. You are telling React: "this effect uses these values." React uses the array to decide when the effect is stale and needs to re-run.

// WRONG — lying to React about dependencies
useEffect(() => {
  const interval = setInterval(() => {
    setCount(count + 1)  // uses count
  }, 1000)
  return () => clearInterval(interval)
}, [])  // ← [] says "no dependencies" — but we use count!
// Bug: count is captured at 0 and never updates — stale closure
 
// RIGHT — use the functional update form to avoid the dependency
useEffect(() => {
  const interval = setInterval(() => {
    setCount(prev => prev + 1)  // does not read count from scope
  }, 1000)
  return () => clearInterval(interval)
}, [])  // ← [] is now honest — the effect has no captured values

The ESLint rule eslint-plugin-react-hooks/exhaustive-deps exists precisely to catch lying dependency arrays. It should always be enabled. When the linter asks you to add something to the array and your instinct is to suppress the warning, that is a signal you need to restructure the code — not silence the linter.

What should go in the dependency array

Everything your effect reads from the component's scope that could change between renders must be in the dependency array. This includes:

// ✓ State variables used inside the effect
useEffect(() => { fetchData(query) }, [query])
 
// ✓ Props used inside the effect
useEffect(() => { document.title = title }, [title])
 
// ✓ Context values used inside the effect
useEffect(() => { applyTheme(theme) }, [theme])
 
// ✓ Functions defined inside the component (they change every render)
const handleData = useCallback(() => { /* ... */ }, [dependency])
useEffect(() => { socket.on('data', handleData) }, [handleData])
 
// ✗ Stable values — do NOT need to be in dependencies:
// - useState setters (React guarantees they are stable)
// - useReducer dispatch (stable)
// - Refs (.current is mutable but the ref object itself is stable)
// - Constants defined outside the component

Cleanup — the half of useEffect most developers get wrong

The cleanup function runs in two scenarios: before the next effect runs (to tear down the previous one), and when the component unmounts. Omitting cleanup causes resource leaks.

// Event listener — cleanup removes it
useEffect(() => {
  window.addEventListener('resize', handleResize)
  return () => window.removeEventListener('resize', handleResize)
}, [handleResize])
 
// Timer — cleanup cancels it
useEffect(() => {
  const id = setTimeout(() => setVisible(false), 3000)
  return () => clearTimeout(id)
}, [])
 
// WebSocket subscription — cleanup unsubscribes
useEffect(() => {
  const sub = stockFeed.subscribe(ticker, onPrice)
  return () => sub.unsubscribe()
}, [ticker])
 
// Fetch with AbortController — cleanup aborts in-flight requests
useEffect(() => {
  const controller = new AbortController()
  fetch(`/api/user/${id}`, { signal: controller.signal })
    .then(r => r.json())
    .then(data => setUser(data))
    .catch(err => {
      if (err.name !== 'AbortError') setError(err)
    })
  return () => controller.abort()
}, [id])

The AbortController pattern is the correct way to handle fetch in useEffect. Without it, if the user navigates away or the id changes before the request completes, the callback runs on an unmounted component — causing the React warning "Can't perform a React state update on an unmounted component."

The stale closure problem — the most common useEffect bug

A stale closure is when your effect captures a value from a render, that value later changes, but the effect still holds the old value because it was not included in the dependency array.

function Counter() {
  const [count, setCount] = useState(0)
 
  useEffect(() => {
    const id = setInterval(() => {
      console.log(count)   // always logs 0 — stale closure
      setCount(count + 1)  // always sets to 1 — never increments
    }, 1000)
    return () => clearInterval(id)
  }, [])  // [] means effect never re-runs — count is permanently captured as 0
 
  return 
{count}
}
 
// Fix 1: Add count to dependencies (but causes interval to restart every second)
useEffect(() => {
  const id = setInterval(() => {
    setCount(count + 1)
  }, 1000)
  return () => clearInterval(id)
}, [count])
 
// Fix 2: Functional update — don't read count at all (best solution)
useEffect(() => {
  const id = setInterval(() => {
    setCount(prev => prev + 1)  // prev is always current — no stale closure
  }, 1000)
  return () => clearInterval(id)
}, [])  // honest [] — no captured values
 
// Fix 3: useRef to hold latest value
const countRef = useRef(count)
useEffect(() => { countRef.current = count })  // sync ref after every render
 
useEffect(() => {
  const id = setInterval(() => {
    setCount(countRef.current + 1)  // reads from ref, always current
  }, 1000)
  return () => clearInterval(id)
}, [])

Data fetching in useEffect — the canonical pattern

function UserProfile({ userId }) {
  const [user, setUser]     = useState(null)
  const [loading, setLoading] = useState(true)
  const [error, setError]   = useState(null)
 
  useEffect(() => {
    let cancelled = false   // flag to prevent state update after unmount
    const controller = new AbortController()
 
    async function fetchUser() {
      try {
        setLoading(true)
        setError(null)
        const res  = await fetch(`/api/users/${userId}`, { signal: controller.signal })
        if (!res.ok) throw new Error(`HTTP ${res.status}`)
        const data = await res.json()
        if (!cancelled) setUser(data)    // guard against unmounted component
      } catch (err) {
        if (err.name !== 'AbortError' && !cancelled) setError(err.message)
      } finally {
        if (!cancelled) setLoading(false)
      }
    }
 
    fetchUser()
 
    return () => {
      cancelled = true        // prevent state updates after cleanup
      controller.abort()      // cancel in-flight request
    }
  }, [userId])  // re-fetch when userId changes
 
  if (loading) return 
  if (error)   return 
  return 
}

This pattern handles: data fetching, loading state, error state, request cancellation on userId change, and prevention of state updates on unmounted components. It is the foundation — React Query, SWR, and TanStack Query build on these same concepts with additional caching, deduplication, and background refresh.

useEffect vs useLayoutEffect — when to use which

// useEffect — asynchronous, runs AFTER browser paint
// Use for: data fetching, subscriptions, analytics, document.title
useEffect(() => {
  fetchData()
}, [id])
 
// useLayoutEffect — synchronous, runs BEFORE browser paint (same timing as componentDidMount/Update)
// Use for: reading DOM dimensions, synchronising scroll position, preventing visual flicker
useLayoutEffect(() => {
  // Runs synchronously after DOM mutations, before paint
  const { height } = ref.current.getBoundingClientRect()
  setTooltipHeight(height)   // layout measurement — must happen before paint
}, [])
 
// Classic tooltip positioning example:
function Tooltip({ children, text }) {
  const ref = useRef()
  const [pos, setPos] = useState({ top: 0, left: 0 })
 
  useLayoutEffect(() => {
    const rect = ref.current.getBoundingClientRect()
    setPos({ top: rect.bottom, left: rect.left })
    // With useEffect, tooltip flickers at wrong position then jumps — user sees flash
    // With useLayoutEffect, position is set before paint — no flicker
  }, [])
 
  return 
{children}
}

Functions as dependencies — the object identity problem

Every render creates new function instances. If you pass a function as a dependency, the effect re-runs every render because the function reference is new every time.

// Bug — fetchData is recreated every render, effect runs every render
function SearchResults({ query }) {
  const fetchData = async () => {      // new function every render
    const res = await fetch(`/api/search?q=${query}`)
    setResults(await res.json())
  }
 
  useEffect(() => {
    fetchData()
  }, [fetchData])   // ← triggers every render because fetchData is always new
}
 
// Fix 1: Move the function inside the effect (no dependency needed)
useEffect(() => {
  async function fetchData() {   // defined inside effect — not in outer scope
    const res = await fetch(`/api/search?q=${query}`)
    setResults(await res.json())
  }
  fetchData()
}, [query])   // only query is a dependency
 
// Fix 2: useCallback to stabilise the function reference
const fetchData = useCallback(async () => {
  const res = await fetch(`/api/search?q=${query}`)
  setResults(await res.json())
}, [query])   // function only recreated when query changes
 
useEffect(() => {
  fetchData()
}, [fetchData])

Objects and arrays as dependencies

// Bug — options is a new object every render
function DataChart({ userId }) {
  const options = { userId, format: 'json' }   // new object every render
 
  useEffect(() => {
    fetchChartData(options)
  }, [options])   // new reference every render → effect runs every render
 
  // Fix 1: Destructure — depend on primitives
  useEffect(() => {
    fetchChartData({ userId, format: 'json' })
  }, [userId])   // userId is a primitive — stable reference when unchanged
 
  // Fix 2: useMemo to stabilise the object reference
  const stableOptions = useMemo(() => ({ userId, format: 'json' }), [userId])
  useEffect(() => {
    fetchChartData(stableOptions)
  }, [stableOptions])
}

Race conditions in useEffect

When the same effect fires multiple times rapidly (user types fast, userId changes quickly), earlier requests can resolve after later ones, writing stale data over fresh data.

// Race condition — user types 'r', 're', 'rea', 'reac', 'react'
// Earlier requests may resolve last, overwriting the 'react' results
useEffect(() => {
  fetch(`/api/search?q=${query}`)
    .then(r => r.json())
    .then(data => setResults(data))   // stale response can win the race
}, [query])
 
// Fix 1: AbortController — cancels the previous request on cleanup
useEffect(() => {
  const controller = new AbortController()
  fetch(`/api/search?q=${query}`, { signal: controller.signal })
    .then(r => r.json())
    .then(data => setResults(data))
    .catch(err => { if (err.name !== 'AbortError') setError(err) })
  return () => controller.abort()   // cleanup aborts previous request
}, [query])
 
// Fix 2: Ignore flag — let the request complete but ignore the result
useEffect(() => {
  let ignore = false
  fetch(`/api/search?q=${query}`)
    .then(r => r.json())
    .then(data => { if (!ignore) setResults(data) })
  return () => { ignore = true }
}, [query])

React 18 and StrictMode double-invocation

In React 18, StrictMode intentionally mounts components twice in development (mount → unmount → remount) to help detect effects that don't clean up properly. This causes useEffect to run twice on mount in development only.

// In React 18 StrictMode, development only:
// 1. Component mounts → effect runs
// 2. Component unmounts → cleanup runs
// 3. Component remounts → effect runs again
// (Only one mount in production)
 
// This double-fire exposes missing cleanups:
useEffect(() => {
  console.log('subscribed')
  return () => console.log('unsubscribed')   // MUST clean up for double-fire to be safe
}, [])
// Console in dev: 'subscribed', 'unsubscribed', 'subscribed'
// If you see doubled API calls in dev, this is why — add abort/cancel in cleanup

Common useEffect anti-patterns

// ❌ Anti-pattern 1: Using useEffect for derived state
function CartTotal({ items }) {
  const [total, setTotal] = useState(0)
  useEffect(() => {
    setTotal(items.reduce((sum, item) => sum + item.price, 0))  // extra render!
  }, [items])
  // ✅ Fix: derive directly
  const total = items.reduce((sum, item) => sum + item.price, 0)
}
 
// ❌ Anti-pattern 2: Using useEffect to sync parent and child state
function Parent() {
  const [parentVal, setParentVal] = useState('')
  return 
}
function Child({ value, onChange }) {
  const [localVal, setLocalVal] = useState(value)
  useEffect(() => setLocalVal(value), [value])   // state sync — fight between React and you
  // ✅ Fix: lift state up fully or use a single controlled input
 
// ❌ Anti-pattern 3: Fetching without loading/error states
useEffect(() => {
  fetch('/api/data').then(r => r.json()).then(setData)  // no loading, no error handling
}, [])
 
// ❌ Anti-pattern 4: Not abstracting repeated effect patterns into custom hooks
// If you write the same fetch-loading-error pattern twice, extract a useFetch hook
 
// ❌ Anti-pattern 5: Using useEffect for event handlers
useEffect(() => {
  document.getElementById('btn').addEventListener('click', handleClick)
  return () => document.getElementById('btn').removeEventListener('click', handleClick)
}, [])
// ✅ Fix: use React's onClick prop — that's what it's for

useEffect vs React Query — when to reach for a library

useEffect is the primitive. React Query, SWR, and TanStack Query are abstractions built on top. Use the library when you need:

• Caching — don't re-fetch data that was recently loaded
• Deduplication — multiple components requesting the same data fire only one request
• Background refetching — stale-while-revalidate pattern
• Optimistic updates — update UI before server confirms
• Infinite scroll / pagination — built-in cursor management

// The same fetch pattern in React Query — eliminates all the useEffect boilerplate
function UserProfile({ userId }) {
  const { data: user, isLoading, error } = useQuery({
    queryKey: ['user', userId],   // cache key — automatically deduplicates
    queryFn: () => fetch(`/api/users/${userId}`).then(r => r.json()),
    staleTime: 5 * 60 * 1000,    // treat data as fresh for 5 minutes
  })
 
  if (isLoading) return 
  if (error)     return 
  return 
}