Frontend Beauty
ESC

Type to search the knowledge base.

Intercepting Routes Overview

Intercepting routes show a parallel UI (modal) while keeping the underlying URL: folder conventions with (.) (..) etc.

advanced3 min read
  • nextjs
  • intercepting-routes

Intercepting routes let you display a route’s UI inside the current layout (often a modal) when navigating from within the app, while a full page load of the same URL shows the standalone page. Soft navigation feels like a modal; shareable URL still works.

Docs: Intercepting Routes.

Convention

app/
  feed/
    page.tsx
    @modal/
      (.)photo/[id]/page.tsx   # intercept /photo/[id] from same level
  photo/
    [id]/page.tsx              # full page

Matchers:

Prefix Meaning
(.) same segment level
(..) one level up
(..)(..) two levels up
(...) from app root

Pair with parallel routes

Modals usually use a slot @modal in the layout defaulting to null:

// app/layout.tsx
export default function Layout({
  children,
  modal,
}: {
  children: React.ReactNode;
  modal: React.ReactNode;
}) {
  return (
    <>
      {children}
      {modal}
    </>
  );
}

See parallel routes.

UX details

  • Close modal → router.back() or link to the underlying page without intercept.
  • Hard reload of /photo/123 should show full page, not empty modal shell.
  • Focus trap and aria-modal still required for a11y.

Interview out-loud

“Intercepting routes use (.) / (..) folder conventions to render another segment’s UI inside the current tree, commonly for modals with shareable URLs. Hard navigation shows the full page. They pair with parallel route slots like @modal.”

Further reading

Edge cases worth rehearsing

Interviewers and production incidents cluster around the same edges: first render versus update, empty and loading states, Strict Mode double setup, concurrent interruptions, and what happens when identity (key, route params, user id) changes mid-edit. Walk one concrete user journey end-to-end — open, edit, navigate away, come back — and say which state survives.

Prefer fixing data flow and ownership before reaching for memoization or micro-optimizations. Prefer event handlers over effects when a user action is the trigger. Prefer deriving values during render over mirroring props into state. Prefer stable list keys from business ids. Measure with the profiler when performance is the claim.

When you cite an API, mention one failure mode: abort on unmount, serializable props across server/client boundaries, focus restoration for dialogs, or cache invalidation after a mutation. Specific beats generic every time.

Quick self-test

Explain the concept in 60 seconds, write a minimal code sample from memory, name one footgun, and point to the primary docs. If any of those fail, reread the worked example and rebuild it in a scratch file until the model sticks under interview pressure.

Edge cases worth rehearsing

Interviewers and production incidents cluster around the same edges: first render versus update, empty and loading states, Strict Mode double setup, concurrent interruptions, and what happens when identity (key, route params, user id) changes mid-edit. Walk one concrete user journey end-to-end — open, edit, navigate away, come back — and say which state survives.

Prefer fixing data flow and ownership before reaching for memoization or micro-optimizations. Prefer event handlers over effects when a user action is the trigger. Prefer deriving values during render over mirroring props into state. Prefer stable list keys from business ids. Measure with the profiler when performance is the claim.

When you cite an API, mention one failure mode: abort on unmount, serializable props across server/client boundaries, focus restoration for dialogs, or cache invalidation after a mutation. Specific beats generic every time.

Related guides