Side-Effect Management When Writing Custom Hooks

Should we not write custom hooks?

Creating custom hooks is one of the strongest ways to abstract repeated logic in React.
But if you use useEffect in the wrong places, you’ll quickly run into infinite loops, memory leaks, or data inconsistencies. 😊

In this post, we’ll cover how to manage side effects in custom hooks, the most common pitfalls, and solid patterns you can rely on.

Quick refresher: What is a side effect?

• Fetching data (fetch)
• Adding event listeners
• Manipulating the DOM or storage
• Timers or subscriptions

A simple custom hook example

function useWindowWidth() {
  const [width, setWidth] = useState(window.innerWidth)

  useEffect(() => {
    const handleResize = () => setWidth(window.innerWidth)
    window.addEventListener('resize', handleResize)

    return () => window.removeEventListener('resize', handleResize)
  }, [])

  return width
}

• Side effect: addEventListener → talks to the outside world.
• Cleanup: removeEventListener → prevents leaks.

Common Mistake #1: Dependency chaos

useEffect(() => {
  fetch(`/api/data?query=${query}`)
}, []) // ❌ missing `query` dependency!

Add the dependency:

useEffect(() => {
  fetch(`/api/data?query=${query}`)
}, [query])

💡 Tip: Don’t disable ESLint’s react-hooks/exhaustive-deps rule. It saves lives.

Common Mistake #2: Missing cleanup

function useTimer() {
  useEffect(() => {
    const id = setInterval(() => console.log('tick'), 1000)
    return () => clearInterval(id)
  }, [])
}

Common Mistake #3: Mixing state and effects in one blob

useEffect(() => {
  setData(fetchData()) // ❌ both state and effect in one go
}, [])

useEffect(() => {
  fetchData().then(setData)
}, [])

const data = useDataFetcher('/api/posts')

Patterns for useEffect inside custom hooks

1) Data fetching

function useFetch(url) {
  const [data, setData] = useState(null)
  const [error, setError] = useState(null)
  const [loading, setLoading] = useState(true)

  useEffect(() => {
    let ignore = false
    setLoading(true)

    fetch(url)
      .then(res => res.json())
      .then(json => { if (!ignore) setData(json) })
      .catch(setError)
      .finally(() => setLoading(false))

    return () => { ignore = true }
  }, [url])

  return { data, error, loading }
}

> Alternative: use AbortController to cancel requests in flight.

2) Event listener management

function useKeyPress(targetKey) {
  const [pressed, setPressed] = useState(false)

  useEffect(() => {
    const down = (e) => e.key === targetKey && setPressed(true)
    const up = (e) => e.key === targetKey && setPressed(false)

    window.addEventListener('keydown', down)
    window.addEventListener('keyup', up)

    return () => {
      window.removeEventListener('keydown', down)
      window.removeEventListener('keyup', up)
    }
  }, [targetKey])

  return pressed
}

Best practices for side-effect management

1. Always return a cleanup. Every effect leaves a trace; remove it yourself.
2. Get the dependency array right. Deterministic dependencies → deterministic behavior.
3. Cancel async work. Prefer AbortController for fetches.
4. Split effects. One useEffect ≠ many responsibilities.
5. Make hooks testable. Keep DOM access out; test with jest / RTL.

Reactive pattern: Effect + Memo combo

function useFilteredList(list, query) {
  const filtered = useMemo(() => list.filter(i => i.includes(query)), [list, query])
  useEffect(() => {
    console.log('List updated')
  }, [filtered])
  return filtered
}

Debugging tips

• In React DevTools → Components, watch your hook values.
• Log how many times effects fire.
• Use the Profiler to detect unnecessary renders.

useEffect(() => {
  console.count('Effect fired')
})

Conclusion

In short:

• Side effect = work outside render.
• Every effect needs a cleanup.
• Dependencies are life-saving.
• Custom hooks should be isolated and testable.