Volume 3

Q179: Routing, Layouts and State Preservation in Next.js

Difficulty: SeniorFrequency: HighAnswer time: 8-12 minutes

What Interviewers Want To Evaluate

This question checks whether you can reason about route architecture in the Next.js App Router. Interviewers want layouts, templates, nested routes, loading and error boundaries, state preservation, route groups, parallel routes, intercepting routes, metadata, and navigation UX.

Senior answers should connect route structure to product workflows.

Short Interview Answer

In the Next.js App Router, layouts persist across navigation for their route segment, while pages change. This lets shared shells, nav, providers, and state survive child route changes. Templates remount on navigation when reset behavior is desired. Loading, error, and not-found files define route-level async and failure boundaries. Good route architecture places persistent UI in layouts, resettable UI in templates or pages, and uses route groups, parallel routes, or intercepting routes when workflows need more advanced structure.

Detailed Interview Answer

The App Router uses file-system conventions.

layout.tsx: persistent wrapper
page.tsx: route content
loading.tsx: loading boundary
error.tsx: error boundary
not-found.tsx: not found boundary
template.tsx: remounting wrapper

These files are not only organization. They define runtime behavior.

Layout State Preservation

Layouts preserve state across navigation within their segment.

Example:

/dashboard/layout.tsx
/dashboard/analytics/page.tsx
/dashboard/settings/page.tsx

The dashboard layout can keep sidebar state while pages change.

This is useful for navigation shells, account switchers, persistent filters, or tab frames.

Page Changes

page.tsx is the unique content for a route.

When navigating between sibling pages, the page changes but shared parent layouts stay.

That means state placement affects whether state resets.

If state should survive, place it in a shared layout or external store.

If state should reset, keep it in the page or use a template boundary.

Templates

Templates remount on navigation.

Use templates when you want layout-like structure but reset behavior.

Examples:

restart animation per page
reset local form state
rerun client setup per navigation
force fresh component lifecycle

Do not use templates where state preservation is valuable.

Loading Boundaries

loading.tsx creates a Suspense boundary for a route segment.

Good loading UI:

preserves shell
matches final layout size
shows section-level skeletons
avoids full-page blankness
does not hide stable navigation

Loading boundaries should match user-perceived readiness zones.

Error Boundaries

error.tsx catches errors in a route segment and must be a Client Component.

It should provide:

clear fallback
retry with reset
safe technical logging
preserved surrounding shell
support path when needed

Segment-level boundaries keep failures local.

Route Groups

Route groups organize routes without changing the URL.

app/(marketing)/page.tsx
app/(app)/dashboard/page.tsx

They are useful for separate layouts:

marketing shell
authenticated app shell
admin shell
docs shell

The group name does not appear in the URL.

Parallel Routes

Parallel routes let a layout render multiple route slots at once.

Use cases:

dashboard with independent panels
master-detail UI
modal slot
split inbox view
complex workspace shells

They are powerful but should be used when the product workflow truly needs independent route regions.

Intercepting Routes

Intercepting routes can show route content in a modal over the current page.

Example:

open photo detail as modal from gallery
open issue detail over list
open checkout step over product page

This preserves context while still allowing direct navigation to the full route.

Metadata

Route metadata should match the content and sharing needs.

In handbook apps, question pages should have useful titles and descriptions.

Dynamic metadata should be generated server-side where possible.

Do not treat SEO as an afterthought for content-heavy sites.

Common Mistakes

A common mistake is putting resettable page state in a persistent layout.

Another mistake is putting persistent shell state in pages and losing it on navigation.

Another mistake is using parallel routes for simple nested UI.

Another mistake is building modal routes without direct-link fallback.

Another mistake is making loading boundaries too high.

Senior Trade-Offs

Route architecture is product architecture.

The best route structure supports navigation, direct links, loading states, error recovery, analytics, metadata, and state lifetime.

Avoid clever routing unless it improves a real workflow.

Debugging Workflow

When route state behaves unexpectedly:

identify which segment owns the state
check layout vs page vs template placement
inspect route groups
check loading and error boundary scope
test back and forward navigation
test direct URL entry
test refresh behavior
test modal route fallback
review metadata output

Interview Framing

Explain layouts, pages, templates, loading and error boundaries, then discuss preservation, route groups, parallel routes, intercepting routes, and product trade-offs.

Revision Notes

In the App Router, file placement defines state lifetime and user experience.

Key Takeaways

Put persistent UI where it should persist, resettable UI where it should reset, and boundaries where users experience loading or failure.

Follow-Up Questions

  1. What does layout.tsx do?
  2. How is template.tsx different?
  3. Where should persistent navigation state live?
  4. What does loading.tsx create?
  5. Why is error.tsx a Client Component?
  6. What are route groups?
  7. When are parallel routes useful?
  8. What are intercepting routes?
  9. How should modal routes support direct links?
  10. How does route structure affect state preservation?

How I Would Answer This In A Real Interview

I would say layouts preserve state across child navigation, pages define route content, templates reset, and loading/error files create segment boundaries. I would structure routes around product workflows, preserving shells and state where useful while keeping direct links, recovery, and metadata clean.