Loading：一秒之后自己跳走Loading: it moves to the next page by itself after one second

In one line: setTimeout is a side effect — it changes something outside the component (the browser’s timer table). Side effects belong in useEffect.

What happens if you put it in the component body:

• Every render starts one more timer, and nobody remembers their ids, so they cannot be cleared;
• React 18’s StrictMode renders twice in development, so one mount starts two;
• Each timer fires onComplete(), so setCurrentPage runs several times — which happens to look fine because it sets the same value, but that is luck.

What goes in the dependency array: the source project writes [onComplete].

That is the honest version — the effect uses onComplete, so it declares it.
It has a consequence, though: App passes down () => setCurrentPage("cab-confirmation"), and every App render creates a new function, so onComplete changed and the effect re-runs (clearing the timeout and starting over).
Nothing bites in this app, because App does not re-render while Loading is on screen — no other state is moving. Change the scene, though — say a clock in the header ticking every second — and the timer is reset forever and the confirmation page never arrives.

Follow-up: “So what do you do?” — two routes: (1) stabilise onComplete with useCallback over in App; (2) use [] as the dependency array and keep the latest onComplete in a ref. (1) is more common, (2) is more thorough. Being able to state the causal chain — new function identity, so the effect re-runs — matters more than reciting either fix.

In one line: return () => clearTimeout(timer) guarantees that when the component leaves, its timer leaves with it.

What actually breaks without it: in this question Loading lives for one second and there is no other way out, so none of the four tests fail if you omit the cleanup.
That is exactly what to be suspicious of — “tests pass” is not “you got it right”, once again.

When a request really does hang: add one Cancel button that lets the user go home during loading —

• At 0.3s the user cancels, setCurrentPage("home") runs, and Loading unmounts;
• At 1s the timer fires and calls onComplete() anyway;
• So setCurrentPage("cab-confirmation") runs — the user is sitting on the home page and it jumps to the confirmation page by itself.

This is not something abstract like “a memory leak”; it is a bug the user can see.
Follow-up: “Doesn’t React warn Can't perform a React state update on an unmounted component?” — that warning was removed in React 18 because it fired too often on correct code. So today skipping the cleanup gives you no warning at all, only strange behaviour.

How the test controls that second:

• vi.useFakeTimers() in beforeEach replaces setTimeout with a fake one, so time does not move on its own;
• act(() => { vi.advanceTimersByTime(1000) }) winds the clock forward one second and the timer fires immediately. The act wrapper is there because firing triggers a setState; without it React warns about an update outside act, and the assertion may run before the re-render;
• vi.runOnlyPendingTimers() then useRealTimers() in afterEach drain any pending timers before restoring, so nothing leaks into the next test.

Which is why the delay has to be exactly 1000. Write 1200 and after advanceTimersByTime(1000) the timer has not fired, the page is still loading, and getByTestId("confirm-message") finds nothing — tests 3 and 4 both go red.