Why useEffect and fetch Are a Bad Combination

useEffect runs after the component renders. That means your component renders once with no data, triggers the effect, fetches the data, then renders again with the data. That's two renders minimum, an empty state you have to handle, and a loading flicker your users see. And that's when nothing goes wrong.

Add a cleanup function wrong and you get stale closures. Miss an edge case in your dependency array and you get infinite loops. React 18 strict mode double-invokes effects in development, so every bug hides behind 'it only happens in production.' I've spent hours debugging data-fetching issues that were entirely caused by this pattern.

The Pattern That Replaced It

In Next.js App Router, Server Components are async. You fetch data directly in the component body with await — no useEffect, no loading state, no race conditions. The component doesn't render until the data is ready. It's how I would have designed data-fetching if I'd been starting from scratch.

For client-side data (user interactions, real-time updates), a library like SWR or React Query handles caching, deduplication, revalidation, and error states in a way no hand-rolled useEffect ever will. The mental model is declarative: 'I need this data' — not 'I need to fetch this data at this point in the lifecycle.'

Key takeaways

  • In Next.js App Router, make your data-fetching components async Server Components — fetch directly in the component body, no useEffect needed
  • For client-side data requirements, SWR or React Query handle caching, deduplication, and revalidation better than any manual useEffect implementation
  • If you're still on Pages Router or a non-Next.js app, at minimum use a loading/error state machine instead of imperative fetch-in-effect

Conclusion

useEffect is powerful and necessary — for subscriptions, DOM mutations, third-party integrations. Data fetching just isn't what it's designed for. Once you stop using it for fetching, you'll be surprised how few legitimate useEffect cases you actually have.

Enjoyed this article?

Vivek Kumar Singh

Vivek Kumar Singh

Technical Expert · Full Stack Cloud Engineer · Tokyo, Japan