useEffect Isn't Bad, You're Just Using It Wrong

If you've been learning React in the last few years, there is a high chance you were taught to fetch data inside useEffect.

useEffect(() => {
  fetch("/api/posts")
    .then((res) => res.json())
    .then(setPosts);
}, []);

At first, this feels normal. But as your apps grow, many React developers move away from this pattern.

So why did that happen?

The short answer is that useEffect got overloaded. Data fetching, DOM work, subscriptions, and one-off logic were all pushed into one hook.

useEffect is not bad. It was just often used for jobs it was never meant to own completely.

In modern React, frameworks like Next.js and libraries like TanStack Query provide better patterns for data loading and async state.

What useEffect Is Actually For

React handles rendering and state. useEffect exists to synchronize your component with systems outside React.

Common examples include:

• Browser DOM
• localStorage
• timers
• animations
• WebSockets
• third-party libraries

A dark mode toggle is a clean use case:

useEffect(() => {
  document.documentElement.classList.toggle("dark", darkMode);
}, [darkMode]);

Saving a preference to localStorage is another good one:

useEffect(() => {
  localStorage.setItem("theme", darkMode ? "dark" : "light");
}, [darkMode]);

In both examples, React state is synchronized with an external system. That is where useEffect shines.

Why Fetching in useEffect Became Popular

Historically, client-side fetching was the default in many React apps.

When hooks arrived, useEffect replaced lifecycle methods like componentDidMount, so this pattern spread quickly:

useEffect(() => {
  fetch("/api/posts")
    .then((res) => res.json())
    .then(setPosts);
}, []);

It worked, so people reused it everywhere.

As apps became more complex, the downsides became obvious. Teams needed retries, caching, invalidation, deduplication, and better loading behavior.

That's when framework-first and library-first data strategies became the better long-term choice.

What Feels Wrong About Effect-Based Fetching

Fetching with useEffect is not forbidden. It just gets expensive in complexity as the app scales.

Delayed Start

Effects run after the first render, so the request starts later than it could.

Typical sequence:

• Component renders
• Browser paints UI
• useEffect runs
• Fetch starts
• Data returns

This can make interfaces feel slower compared with server-side fetching.

Boilerplate Repetition

Even a simple fetch often expands into state plumbing:

const [data, setData] = useState(null);
const [loading, setLoading] = useState(true);
const [error, setError] = useState(null);

useEffect(() => {
  fetch("/api/posts")
    .then((res) => res.json())
    .then(setData)
    .catch(setError)
    .finally(() => setLoading(false));
}, []);

Now multiply that across many pages and components.

You end up rebuilding the same system repeatedly:

• Loading states
• Error handling
• Retries
• Caching
• Refetching
• Deduplication

No Built-In Caching

useEffect does not cache results by default. Remounting can trigger repeat requests unless you build caching yourself.

Strict Mode Confusion

In development, React Strict Mode can run effects twice, which often surprises people with duplicate requests.

Performance Costs

Heavy client-side fetching can increase:

• Hydration work
• Loading spinners
• Client-side JavaScript
• Layout shifts

Better Modern Alternatives

Modern React did not remove useEffect. It replaced the idea that useEffect should handle everything.

Today, concerns are usually split like this:

• useEffect handles side effects
• Framework handles server data
• Data libraries handle async caching and synchronization

That separation scales better and keeps components cleaner.

Fetching With Next.js

In Next.js, data can be fetched on the server before the page is sent to the browser.

async function Page() {
  const posts = await fetch("https://api.example.com/posts").then((res) => res.json());

  return <PostList posts={posts} />;
}

Benefits usually include:

• Less client-side JavaScript
• Improved SEO
• Fewer loading states
• Better initial performance
• Built-in caching options

Fetching With TanStack Query

Client fetching is still valid when data is user-specific or frequently changing.

Good examples:

• Frequently changing data
• Authenticated requests
• Background updates
• Optimistic UI
• Data tied to client interaction

TanStack Query handles the async concerns for you:

const { data, isLoading, error } = useQuery({
  queryKey: ["posts"],
  queryFn: getPosts,
});

Compared with manual effect-based fetching, this is often easier to scale and maintain.

So Where Does useEffect Fit?

useEffect is still excellent for real side effects.

useEffect(() => {
  const interval = setInterval(() => {
    console.log("Still running");
  }, 1000);

  return () => clearInterval(interval);
}, []);

And for browser synchronization tasks:

useEffect(() => {
  localStorage.setItem("theme", theme);
}, [theme]);

The difference is simple: useEffect synchronizes with external systems. It should not become your full data architecture.

Should You Avoid useEffect?

No. You just should not reach for it automatically.

A useful rule of thumb:

If your component must sync with something outside React, useEffect is likely appropriate.

Examples:

• Timers
• Event listeners
• Browser APIs
• Subscriptions
• Animations
• Theme sync
• localStorage

Another common issue is using effects for derived values that can be computed during render.

Avoid this pattern:

const [fullName, setFullName] = useState("");

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

Prefer this:

const fullName = `${firstName} ${lastName}`;

This removes unnecessary state and extra renders.

Final Thoughts

useEffect is not the enemy. Treating it like the answer to every problem is what caused the controversy.

When effects become your data layer, state manager, and caching system, things get messy.

That is why modern React moved toward:

• Server-side fetching in Next.js
• Dedicated async state tools like TanStack Query
• Fewer unnecessary effects

useEffect still has an important place:

• Theme synchronization
• localStorage
• Subscriptions
• Event listeners
• Browser APIs

The key distinction is understanding the difference between synchronizing with external systems and building your entire app architecture inside a hook.

Conclusion

For years, developers treated useEffect as a universal solution for data, derived state, and synchronization.

Modern React matured beyond that approach:

• Server-side fetching in Next.js
• Async state management with TanStack Query
• Fewer unnecessary client-side effects

useEffect is still valuable. The goal is not to avoid it, but to use it for the right job.