Frontend Beauty
ESC

Type to search the knowledge base.

Parallel Routes Overview

Parallel routes render multiple pages in one layout via named slots (@folder), independent loading, and modals.

advanced3 min read
  • nextjs
  • parallel-routes

Parallel routes let a layout render multiple pages at once using named slots (@folder). Each slot can load, error, and navigate somewhat independently — ideal for dashboards and modal patterns.

Docs: Parallel Routes.

Slot structure

app/
  dashboard/
    layout.tsx
    page.tsx
    @analytics/
      page.tsx
    @team/
      page.tsx
// app/dashboard/layout.tsx
export default function Layout({
  children,
  analytics,
  team,
}: {
  children: React.ReactNode;
  analytics: React.ReactNode;
  team: React.ReactNode;
}) {
  return (
    <div className="grid">
      <div>{children}</div>
      <aside>{analytics}</aside>
      <section>{team}</section>
    </div>
  );
}

Slots become props on the layout named after the @folder.

default.js

When a slot cannot match a route on hard navigation, provide default.tsx so Next knows what to render (often null for modals).

// app/dashboard/@analytics/default.tsx
export default function Default() {
  return null;
}

Independent loading

Each slot can have its own loading.tsx and error.tsx, so one slow panel does not block siblings — pairs with streaming.

Modals

Combine parallel @modal slot + intercepting routes for Instagram-style photo modals.

Interview out-loud

“Parallel routes use @slot folders so a layout can render multiple page trees at once with independent loading states. default.js handles unmatched slots on hard loads. They power dashboards and modal URL patterns with intercepting routes.”

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