Three components on the same React screen each call a custom `useUser()` hook that fetches `/api/user` inside its own `useEffect`. Why does the page send three identical requests, and why does navigating away and back send three more?

## Why three components means three requests Hooks are per instance. When React mounts a component it allocates that instance's own hook state, and `useEffect` schedules a callback tied to that instance. `useUser()` extracted into a custom hook does not create shared state — a custom hook is just a function that calls hooks, so calling it in three components produces three independent sets of `useState` slots and three separate effects. Critically, the effect has no identity for the work it does. React sees a function to call after commit. It does not know the function will hit `/api/user`, cannot compare that URL against anything, and has no table in which to record "this request is already in flight". Deduplication requires knowing that two requests are *the same request*, and only a layer that models requests as keyed entries can know that. ## Why navigating away and back refetches Unmounting destroys the instance's hook state. There is no persistence layer under `useState`: the fetched object becomes garbage as soon as nothing references it. Remounting gives you a brand-new instance whose `data` starts at its initialiser, and the mount effect fires again. From React's perspective this is correct behaviour, not a leak — it is just that "correct" here means "forgets everything". The HTTP cache sometimes hides this. If the response carries cache headers the browser may serve the repeat request from disk, which makes the problem invisible in development and very visible on an endpoint that sends `Cache-Control: no-store`. Never rely on it: the HTTP cache is not under your control, does not dedupe concurrent in-flight requests reliably, and does nothing for a POST-shaped API or a GraphQL endpoint. ## What a shared cache adds Moving the fetch behind a cache that lives outside the component tree changes the model from *component owns a request* to *component reads a key*: - **In-flight dedupe** — three simultaneous readers of the same key join one request instead of starting three. - **Reuse across mounts** — returning to a screen renders the stored value immediately, often while a background refresh runs. - **A single copy of the truth** — three components rendering the same entity cannot drift apart, which they easily can when each holds its own `useState` copy. - **An explicit staleness policy** — how long a value is considered fresh, whether to revalidate on focus or reconnect, and how a mutation invalidates related entries. - **Retry and error policy in one place**, rather than reimplemented per component. That list is the honest answer to "why not just use `useEffect`": not that effects are wrong, but that everything above is a cache concern, and a cache is exactly what a per-instance effect cannot be. ## The in-React middle ground and its cost The obvious first move is to lift the fetch: one ancestor fetches, and the three children read the value through props or context. That genuinely fixes the triple request while the screen is mounted, and it is the right answer for a small app. What it does not give you is anything about *time*. You now own the questions a cache exists to answer: when is this value too old to show, what refetches it after a mutation elsewhere in the app, what happens when two screens want the same entity under different providers, and what keeps the data alive across an unmount. Answering those inside your own provider is how teams end up writing a cache accidentally, one requirement at a time — which is the usual justification for adopting a purpose-built data layer instead. ```jsx // Per instance, and therefore per request: function useUser() { const [user, setUser] = useState(null); useEffect(() => { fetch('/api/user').then((r) => r.json()).then(setUser); }, []); return user; } ``` ## A related trap Because each copy holds its own snapshot, a mutation made through one component does not update the other two. Each one keeps rendering the value it fetched, and the screen shows the same entity in two different states until something forces a remount. That inconsistency is often what finally pushes a codebase off per-component fetching — it reads as a data bug rather than an architecture choice.