skip to content

A user opens a deep link to a detail screen in a fresh tab; what must the application handle that clicking through never exercises?

level: seniorimportance: must knowfreq 56%

answer

  1. the address is the only input
  2. no warm cache, no parent context
  3. parallel resolution, not a waterfall
  4. a deleted target needs a designed outcome
  5. the link beats remembered session selections

basics

~20 s

A cold deep link starts with nothing but the address: no loaded records, no parent context, no earlier session selections. The screen must resolve every identifier itself, render a real loading state, and handle missing or mismatched targets.

solid answer

~50 s

Clicking through hands the next screen a great deal for free - the record the list already loaded, the parent's name for the breadcrumb, the workspace the user picked three screens ago, a warm runtime. A pasted link has **only the address**. So the screen treats its identifiers as its sole input: it fetches what the previous screen would have handed over, renders a genuine loading state instead of assuming data is present, and resolves independent pieces in parallel rather than in a waterfall where each nested part waits for its parent. It also answers cases in-app navigation never produces: the entity has been deleted, the identifier belongs to a context the session is not in, or the parameters come from an old link whose vocabulary no longer exists. Each needs a designed outcome at that address, not a blank screen.

go deeper

for a junior

Remember that opening a link directly is not the same as clicking into a screen: nothing is loaded yet, so the screen must fetch from the identifiers in the address and show a loading state rather than assuming the data is there.

for a middle

Explain what in-app navigation hands over for free - the already-loaded record, parent names, session selections, a warm cache - and therefore what a cold load has to fetch or derive for itself.

for a senior

Demonstrate the production judgment: parallel resolution instead of a waterfall, a designed not-found outcome at the requested address, the address beating remembered context, and cold-load tests per route.

for a principal

Make deep-linkability a standard the team designs to rather than a bug class it fixes: every screen a function of address plus data, cold-load cases in the definition of done, and old-link tolerance decided deliberately.

## Why a pasted address is a different code path When a user clicks from a list into a detail screen, the application is already running and already knows a great deal. When the same address arrives in a fresh tab - from a chat message, a bookmark, an email, a support ticket - the application starts from nothing and **the address is its entire input**. Most "works for me" defects in client-rendered applications live in that gap, because development and demos are almost entirely click-through. ## What in-app navigation silently provides - **The target record itself.** The list already fetched the row, so the detail screen can render immediately from what sits in memory or in the client cache. - **Parent context.** The breadcrumb's ancestor names, the collection the entity belongs to, the counts in the header - all loaded by screens the user passed through. - **Session-level selections.** The chosen account, workspace, locale or date range the user set earlier and that no longer appears in the address. - **Derived state.** Which rows were selected, what the previous filter was, where the user came from so a Close button can go somewhere sensible. - **A warm runtime.** Code for the screen is loaded, caches are populated, the session is established. A cold load provides none of it, so anything the screen reads without fetching is undefined at exactly the moment a shared link is opened. ## The failure modes worth designing for 1. **Rendering before data.** The screen reads fields off an object it expected in the cache. In-app it is there; cold it is not, and the screen either fails or renders a skeleton of empty labels. Every deep-linkable screen needs a real loading state driven by its own request, not by an assumption. 2. **A waterfall of requests.** The parent loads, then the child, then the child's child, because each level starts only once its parent resolved. Click-through hides this because the upper levels were already in memory; cold it is the whole time-to-content. Start independent requests together, from the identifiers the address already provides. 3. **A target that is gone.** The entity was deleted or archived after the link was sent. The screen needs an explicit not-found outcome, presented at the same address, with a way onward - not a spinner that never resolves, and not a redirect that hides what the link asked for. 4. **A context mismatch.** The address names an entity in one account, workspace or tenant while the session's remembered selection is another. The link should win: the address is the more specific and more recent statement of intent. That usually means switching the ambient context to match the address, or telling the user plainly that the link belongs elsewhere. 5. **An outdated vocabulary.** Old links carry parameter names, option spellings or identifier formats that have since changed. Parsing needs a fallback, and ideally the screen indicates when it could not reproduce everything the link asked for. 6. **Secondary state whose referent vanished.** The address asks for an open panel showing a child item that no longer exists. The primary view should still render, with the panel resolved to a not-found state rather than failing the whole screen. ## Designing for the cold path | Concern | Cold-load design | |---|---| | Input | identifiers and parameters from the address only; assume no cached record | | Fetching | start independent requests in parallel as soon as the address is parsed | | Waiting | a loading state the screen owns, shaped like the real content | | Missing | a not-found view at the requested address, with a route onward | | Mismatch | the address beats remembered session selections | | Unreadable parameters | fall back to defaults and show that the view was not fully reproduced | The underlying principle: **the screen is a function of its address plus fetched data**, never of what a previous screen happened to leave behind. Whatever the previous screen passed along is an optimisation - useful for showing something instantly, never a precondition for correctness. ## How to test it The cheapest effective habit is to stop clicking. For every deep-linkable screen, open the address directly in a new tab with an empty client cache and watch what happens. Then extend that into automated coverage: - Load each route template cold with a valid target and assert the content appears. - Load it cold with an identifier that does not exist and assert the not-found view at that address. - Load it cold while the session's remembered context differs from the address, and assert the address wins. - Load it cold with a malformed or unknown parameter and assert the screen still renders with defaults. - Throttle the data requests and assert the loading state renders rather than empty scaffolding. Those five cases cover almost all of the gap between "works when I click through" and "works when a customer pastes the link into a ticket".

  • The address names an entity in one workspace while the session remembers another. Which wins?
    The address. It is the user's explicit, current intent, while the remembered selection is a stale convenience. The cold load should resolve the entity, switch the ambient context to match it, and only if that is not permitted explain that the link belongs to a different workspace - never render another workspace's data at that address.
  • Why does a deep link expose request waterfalls that click-through never shows?
    Because click-through already paid for the upper levels: the parent data sits in the client cache, so only the last request remains. Cold, every level runs, and if each one starts after its parent resolves the latencies add up serially. The fix is to start everything the address already identifies at once.
  • Should a missing target redirect to the parent list instead of showing a not-found screen?
    Usually not. Redirecting destroys the evidence of what the link asked for, which matters when a colleague or a support agent sent it. Render a not-found view at the requested address, name what was not found, and offer the parent as a link the user chooses to follow.

saying these in an interview costs you the question

  • Assuming the target record is already in the client cache when the screen renders
  • Treating a deleted target as an unexpected error instead of a designed outcome
  • Letting a remembered workspace or account override what the address names
  • Loading nested data in a chain, so cold latency is the sum of every level
  • Testing only by clicking through the application, never by pasting the address
  • Failing the whole screen when a secondary panel's referenced item is missing