While a lazily loaded route's code is in flight, what decides whether the user keeps the previous screen or sees a fallback?

## The same wait, two possible owners When a route entry names a module loader, something has to happen on screen between the click and the moment the route's code is in memory. Which of two things happens is not a property of lazy loading; it is a choice about **who owns the pending period**. - The **router** can own it: it starts the loader, keeps the current screen mounted, exposes a "navigation in progress" signal, and commits the new branch only once the module has resolved. - The **new branch** can own it: the router commits immediately, the route's component is not available, so the nearest **async boundary with a fallback** renders that fallback in place of the suspended subtree. Both are legitimate. They differ in what the user loses during the wait. ## Holding the previous screen The old screen stays mounted, so its scroll position, open menus, partially typed text and in-flight work all survive. Nothing flashes, because nothing is replaced until there is something real to replace it with. The cost is that the app **must** show the pending signal somewhere, or the click looks ignored: users who get no acknowledgement click again, which at best is a duplicate navigation and at worst starts a second one. Because most route bundles resolve quickly on a warm connection, many implementations reveal the pending signal only after a short delay — long enough that a fast load shows nothing at all, short enough that a slow one is acknowledged well before the user doubts the click. ## Committing and showing a fallback Here the new branch mounts at once, and the region whose code has not arrived renders its fallback: a skeleton, a spinner, a placeholder layout. The old screen is torn down immediately, so anything unsaved in it is gone. The benefit is honesty about the destination — the user sees the shape of where they are going, and any part of the new branch whose code *is* already present renders straight away rather than waiting for the slowest sibling. Two details decide how good this feels. The **nearest** enclosing boundary is the one that shows, so a fallback placed high in the tree blanks more of the screen than one placed just around the lazy route. And a fallback for a load that finishes inside a frame or two produces a visible flash: content, skeleton, content. | | Hold the previous screen | Commit and show a fallback | |---|---|---| | What the user sees first | the old screen plus a progress cue | the new layout with a placeholder region | | Old screen state | preserved until commit | discarded at once | | Risk on a fast load | none, if the cue is delayed | a one-frame flash of skeleton | | Risk on a slow load | the app looks stuck without a cue | a long stare at an empty shape | | Fits | short, likely-fast loads; forms and editors | slow or unpredictable loads; content screens | ## Choosing between them - Prefer holding the old screen when the current screen holds user work, when the load is usually fast, or when the two screens look similar enough that a skeleton adds no information. - Prefer a fallback when the wait is long or variable, when the old screen is now misleading (the user has already left it conceptually), or when part of the new branch can render immediately and only one region is waiting. - Do not do both for the same wait. A global progress bar *and* a full-page skeleton reads as two separate things going on. - Whichever you pick, the pending period needs a defined end in both directions: resolved, and failed. A fallback with no sibling failure path becomes a permanent skeleton the first time a bundle request fails. ## Traps worth naming - **The unacknowledged click.** Holding the old screen with no cue at all is the worst of the options, and it is also the default if nobody renders the pending signal. - **The skeleton flash.** Adding a fallback for a bundle that resolves in tens of milliseconds makes a fast app look busy. - **Layout jump.** A fallback whose height differs from the real content shifts the page when it swaps. - **Losing input.** Committing immediately unmounts the previous screen; if it held a half-finished form, the wait has cost the user data, not just time. - **Assuming there is a wait at all.** On the second visit the module is already resolved, so neither branch of this choice is exercised, which is why the pending path is easy to leave untested.