Parallel Routes: @slot Layout Rendering & Conditional Routing
- Last updated
- Prerequisites:
- Next.js App Router basics (layouts, pages)
- Understanding of the file-system routing model
- nextjs
- parallel-routes
- slots
- app-router
- layouts
- conditional-routing
Read at your depth
The practical view
Parallel routes let you render multiple pages in the same layout simultaneously using named slots. Create folder(s) with @ prefix: app/@feed/page.tsx and app/@analytics/page.tsx, then in app/layout.tsx render them: {children} and {feed} and {analytics} (the slot names are passed as props to the layout). Each slot renders independently, and navigating updates each slot separately. The default.tsx file provides a fallback for a slot when the current URL has no matching page. This is ideal for dashboards with independent sections.
The same idea in other frameworks
React Router's outlets in a layout and conditional rendering approaches are the conceptual analogues.Angular named router-outlets are the closest analogue to @slot parallel routes.Vue Router's named views (router-view name=...) map to the same idea.SvelteKit's layout slots (multiple children) approximate parallel rendering.Legacy vs modern
Single outlet vs parallel slots in a dashboard
A single outlet forces one page per layout region; parallel @slots render independent page trees in the same layout simultaneously.
app/dashboard/page.tsx — one page rendering everything: <Feed /><Analytics />app/@feed/page.tsx + app/@analytics/page.tsx rendered via {children}, {feed}, {analytics}Interview gotchas
Context
This tests the slot resolution fallback mechanism — interviewers want to know how the router handles partial URL-to-slot matches, a common source of 404s in parallel-route apps.
The mechanical answer
Each @slot is resolved against the current URL. If the URL matches a page in only some slots (e.g. navigating to /dashboard/settings while only the @settings slot has that page), the unmatched slots must still render something — default.tsx provides that fallback. Without a default.tsx for a slot with no matching page, the router renders a 404 for that slot (or the whole page errors). default.tsx is the equivalent of the slot's home page for unmatched paths. Best practice is to provide default.tsx for every parallel slot that might be unmatched during navigation, especially when slots are conditionally rendered.
Trap
The naive answer is 'missing slots are just skipped'. Without default.tsx the router can 404 the entire route. Another trap: thinking default.tsx only matters for full-page loads — it is also used during client-side navigation when a slot's segment is unmatched. Candidates who describe the per-slot resolution and the fallback file show real App Router knowledge.
Context
This probes the route-tree mechanics — how slots share the layout yet keep independent subtrees, and why navigation can avoid re-rendering unaffected slots.
The mechanical answer
The layout component receives each slot as a prop, so the layout is rendered once with multiple children subtrees. Each slot is its own branch in the route tree; during client navigation, the router computes a diff between the previous and next route trees and updates only the changed branches — the React reconciliation is scoped per slot. So navigating within @feed does not re-render @analytics (its subtree and RSC payload are untouched). The slots share the parent layout's shell (headers/nav) and any providers in it. This is what enables the fast, independent section updates that make dashboards feel like SPAs within the App Router.
Trap
The naive answer is 'parallel routes re-render the whole layout on any navigation'. The router patches only changed slot branches. Another trap: assuming slots share URL state automatically — each slot is keyed to its own segment, so two slots do not magically share query params unless you wire them. Candidates who describe the per-branch patching and slot independence show real understanding.