Parallel Routes

The plain-language idea

Normally a layout has exactly one thing to render: whatever children resolves to for the current URL. Parallel routes let a layout render more than one independently-routable piece of UI at the same time, side by side, each in its own slot.

A slot is a folder named @slotName — the @ prefix, like route groups' parentheses, means "this folder doesn't add itself to the URL." Instead, it gets passed to the parent layout.tsx as a prop named after the slot. app/dashboard/@team/page.tsx and app/dashboard/@analytics/page.tsx don't create /team or /analytics routes — they fill team and analytics props on app/dashboard/layout.tsx, both rendering at /dashboard simultaneously.

children itself is secretly just another slot — app/dashboard/page.tsx is equivalent to an implicit app/dashboard/@children/page.tsx — which matters for the one hard rule every slot has to follow.

See it in a real thing: a dashboard layout with two independent slots

// app/dashboard/layout.tsx
export default function DashboardLayout({
  children,
  team,
  analytics,
}: {
  children: React.ReactNode;
  team: React.ReactNode;
  analytics: React.ReactNode;
}) {
  return (
    <>
      {children}
      <div className="grid grid-cols-2 gap-4">
        {team}
        {analytics}
      </div>
    </>
  );
}

A dashboard layout with two named slots, @team and @analytics, both passed to it as props and rendered side by side.

BackNext

team and analytics render concurrently, each streaming and erroring independently — a slow @analytics query doesn't block @team from showing up, and each slot can have its own loading.tsx and error.tsx. The trickiest real behavior lives in what happens when one slot doesn't have a matching subpage for the current URL. Navigate client-side (clicking a <Link>) to /dashboard/settings, and if only @team has a settings page, Next.js just keeps @analytics showing whatever it last had — that's a soft navigation, and the router can recover the previous state. But hit refresh, or land on that URL from a fresh full-page load — a hard navigation — and the router has no "previous state" to fall back on for the unmatched slot. It looks for a default.tsx in that slot's folder to render as the fallback. If there isn't one, that slot 404s, taking the whole page down with it.

What people usually miss

Watch out

• @slot folders never appear in the URL. /dashboard/@analytics/page.tsx still resolves under /dashboard, not /dashboard/analytics — the slot only affects which prop the content lands in on the parent layout.
• default.tsx only matters on hard navigation. Soft (client-side) navigations preserve each slot's last-active state regardless of whether the current URL matches it; default.tsx is purely the answer to "what renders on a full page load when there's no state to preserve."
• A missing default.tsx on a hard navigation isn't a soft failure — it's a 404 for the whole route, not just a blank slot. This is deliberate: Next.js would rather fail loudly than silently render a parallel slot somewhere it was never intended to appear.
• children needs a default.tsx fallback too, since it's an implicit slot — this is the one people forget most, because it doesn't look like a slot in the folder structure at all.
• If one slot at a route level is dynamically rendered, every slot at that level must be — you can't mix a statically prerendered slot with a dynamically rendered one side by side.

Why this matters in interviews

"Your dashboard has independent widgets that should stream in separately — how would you structure that in the App Router, and what breaks on a page refresh if you get it wrong?" tests real, hands-on parallel-routes experience specifically because the hard-navigation/default.tsx gotcha only shows up once you've actually hit a 404 from it in practice.