In React, when you return a function from the callback you pass to useEffect, what does React do with that function and when does it call it?

## What the returned function is `useEffect` takes a setup function. Anything that function returns is treated as its **cleanup** — the instruction for undoing whatever this particular run set up. Returning nothing is legal and means "there is nothing to undo". Returning anything other than a function is a bug: React only knows how to call a function. ```js useEffect(() => { const id = setInterval(tick, 1000); // setup return () => clearInterval(id); // cleanup for THIS run }, [tick]); ``` ## The pairing rule The mental model that makes every other detail fall out: **each run of the effect produces at most one cleanup, and React calls that cleanup exactly once.** The effect is not a lifecycle hook that fires "on mount" and "on unmount"; it is a repeatable setup/teardown pair that React re-executes whenever the dependencies say the setup is out of date. So across a component's life you get a strictly alternating sequence: ``` setup(run 1) ... cleanup(run 1) -> setup(run 2) ... cleanup(run 2) -> setup(run 3) ... ``` React never runs two setups back to back without the cleanup in between, and it never leaves the final cleanup uncalled when the component goes away. ## When cleanup runs There are exactly two triggers. **1. Before the effect runs again.** After a re-render where at least one dependency changed by React's comparison, React calls the previous cleanup *first*, then runs the new setup. The order matters: the old subscription is closed before the new one opens, so you never briefly hold two. If nothing in the dependency array changed, React skips both — no cleanup, no setup, the previous run simply stays live. **2. On unmount.** When the component is removed from the tree, React calls the last cleanup that is still outstanding. This is what stops a timer or listener from outliving the component that created it. A consequence people get wrong in interviews: with an empty dependency array `[]` the cleanup is not dead code. It never runs *between* renders because the dependencies never change — but it still runs once, at unmount. In development, React deliberately mounts, unmounts and remounts a component once so that a missing or wrong cleanup shows up immediately as a doubled timer or a leaked listener; production runs the pair once. ## What the cleanup can see The cleanup is created inside the same call as the setup, so it closes over that render's variables — the `id` above is the id of *this* run's interval, not of the interval that is about to be created. That is precisely why teardown works when the effect re-runs: the outgoing cleanup refers to the outgoing resource. Never try to clean up "whatever is current"; clean up what this run created. ## The async trap ```js // wrong: an async function returns a promise, not a cleanup useEffect(async () => { const data = await load(); setData(data); }, []); ``` React receives a promise where it expected a cleanup function and warns that an effect must return either a function or nothing. Note the failure is silent in behaviour terms — the effect still runs, you just have no teardown. The fix is to declare the async function inside and call it: ```js useEffect(() => { let cancelled = false; (async () => { const data = await load(); if (!cancelled) setData(data); })(); return () => { cancelled = true; }; }, []); ``` ## Why the discipline pays Every effect that acquires something — a timer, a handle, a listener, an open connection — must hand back the matching release. If you omit it, each re-run stacks another live resource on top of the last, and unmount leaves the final one running against a component that no longer exists. The symptom is the classic one: work that gets faster and faster as a screen is revisited, or callbacks firing after a component has been closed. Writing the cleanup in the same breath as the setup, before you move on, is the habit that prevents the whole class of bug.