useEffect lets you run side effects after render — and data fetching is a side effect (it's not part of computing the UI, it talks to the outside world). So historically it's the place to fetch.

The basic pattern

function UserProfile({ userId }) {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    let cancelled = false;
    const controller = new AbortController();

    setLoading(true);
    setError(null);

    fetch(`/api/users/${userId}`, { signal: controller.signal })
      .then((res) => {
        if (!res.ok) throw new Error(`HTTP ${res.status}`);
        return res.json();
      })
      .then((json) => { if (!cancelled) setData(json); })
      .catch((err) => { if (!cancelled && err.name !== "AbortError") setError(err); })
      .finally(() => { if (!cancelled) setLoading(false); });

    return () => { cancelled = true; controller.abort(); }; // cleanup
  }, [userId]); // re-fetch when userId changes

  if (loading) return <Spinner />;
  if (error) return <Error err={error} />;
  return <Profile data={data} />;
}

Why each piece matters

• The dependency array — [userId]: fetch on mount and whenever userId changes. [] = once on mount. Wrong deps → stale data or refetch loops.
• Three states — loading, error, data. Skipping error is the most common bug.
• Cleanup is essential — without it you get two real bugs:

1. Race condition — userId changes from A to B; both requests are in flight; A resolves after B → you show A's data for B. The cancelled flag (or aborting) discards the stale response.
2. setState after unmount — component unmounts before the fetch resolves; setting state on it warns/leaks. The flag guards against it.

• AbortController actually cancels the in-flight request, not just ignores it.

Why useEffect-fetching is discouraged for real apps

It works, but you end up hand-rolling: loading/error state, cancellation, caching, dedup, refetch-on-focus, retries, pagination — for every fetch. That's a lot of boilerplate and bug surface. So:

• React Query / SWR — purpose-built: caching, dedup, background refetch, retries, stale-while-revalidate, all the race/cleanup handling done for you.
• Framework data loading — Next.js Server Components / route loaders, React Router loaders — fetch before/outside render, no client waterfall.
• React's own guidance now: "you might not need an Effect" — useEffect is for synchronizing with external systems, and data fetching is better served by a dedicated layer.

How to answer

"useEffect runs after render, so it's the classic spot to fetch on mount or when a dependency changes — you set loading/error/data state and, critically, return a cleanup that cancels or ignores stale responses to avoid race conditions and setState-after-unmount. But for production I'd use React Query or SWR, or framework data loading — useEffect fetching means hand-rolling caching, dedup, and cancellation for every call. React's current guidance is that Effects are for syncing with external systems, and data fetching has better tools."