What Are the Basics of the Next.js App Router?
Learn the basics of the Next.js App Router: file-system routing, nested layouts, loading.tsx, error.tsx, and Server Components.
Expected Interview Answer
The Next.js App Router is a file-system-based routing convention built on the `app/` directory where folders define URL segments, `page.tsx` files make a segment publicly routable, and special files like `layout.tsx`, `loading.tsx`, and `error.tsx` provide shared UI and states for that segment and its children.
Each folder under `app/` maps to a URL segment, and a folder becomes an actual route only when it contains a `page.tsx`; folders without one are just organizational or provide shared layout. `layout.tsx` wraps a segment and all its nested children, persisting across navigations without remounting, which is ideal for navbars or sidebars that shouldn’t reset state. `loading.tsx` automatically wraps the segment in a Suspense boundary and shows while the segment’s data is being fetched, and `error.tsx` establishes an error boundary for the segment. Dynamic segments use bracket syntax like `[id]`, and route groups using parentheses like `(marketing)` let you organize routes without affecting the URL. Components inside `app/` are Server Components by default, so data fetching happens server-side unless a file opts into a client directive.
- File-system routing removes the need for a separate route configuration file
- Nested layouts persist across navigations without unnecessary remounts
- Built-in loading and error UI per route segment via loading.tsx and error.tsx
- Server Components by default reduce client bundle size out of the box
AI Mentor Explanation
The App Router is like a stadium’s physical layout defining the fan experience: the main gate (root layout) applies to everyone, a stand-specific entrance (nested layout) adds seating rules only for that stand, and a folder without a turnstile (no page.tsx) is just a storage area, not somewhere fans can enter. A "match delayed" screen (loading.tsx) automatically shows while the scoreboard data loads for that stand only. That folder-maps-to-a-physical-zone, shared-wrapper-persists-across-visits model is exactly how the App Router structures routes and layouts.
Step-by-Step Explanation
Step 1
Create a folder for the URL segment
Each folder under app/ corresponds to a URL path segment, e.g. app/blog/[slug]/.
Step 2
Add page.tsx to make it routable
A folder is only a navigable route once it contains a page.tsx exporting the segment’s UI.
Step 3
Add layout.tsx for shared, persistent UI
layout.tsx wraps the segment and its children, staying mounted across navigations within that subtree.
Step 4
Add loading.tsx / error.tsx as needed
These automatically wrap the segment in Suspense and error boundaries without manual wiring.
What Interviewer Expects
- Understanding that a folder needs page.tsx to become an actual route
- Clear explanation of nested layouts persisting across navigation
- Awareness of special files: loading.tsx, error.tsx, and their automatic boundary behavior
- Knowledge that components in app/ are Server Components by default
Common Mistakes
- Assuming every folder under app/ is automatically a route even without page.tsx
- Believing layout.tsx remounts on every navigation like a regular component
- Forgetting that route groups (parentheses) don’t affect the URL path
- Not knowing Server Components are the default and “use client” must be explicit
Best Answer (HR Friendly)
“The App Router organizes pages using folders and files: a folder becomes a page on your site once you add a page file inside it, and you can add shared layouts, loading screens, or error screens that automatically wrap that section without extra setup. It keeps routing simple because the file structure itself defines the site’s URLs.”
Code Example
// app/dashboard/layout.tsx — persists across all /dashboard/* navigations
export default function DashboardLayout({ children }: { children: React.ReactNode }) {
return (
<div>
<DashboardSidebar />
<main>{children}</main>
</div>
)
}
// app/dashboard/loading.tsx — auto Suspense fallback while page.tsx data resolves
export default function Loading() {
return <p>Loading dashboard...</p>
}
// app/dashboard/page.tsx — the actual routable page
export default async function DashboardPage() {
const stats = await getDashboardStats()
return <StatsGrid stats={stats} />
}Follow-up Questions
- What is the difference between a route group and a dynamic segment?
- How does loading.tsx relate to React Suspense under the hood?
- When would you use a parallel route or an intercepting route?
- How does the App Router differ from the older Pages Router?
MCQ Practice
1. What makes a folder under app/ an actual navigable route?
Only folders containing page.tsx become publicly accessible routes.
2. What happens to layout.tsx when navigating between child routes it wraps?
Layouts persist across navigations within the segment they wrap, avoiding unnecessary remounts.
3. What does loading.tsx automatically provide?
loading.tsx wraps the segment in a Suspense boundary and displays while data resolves.
Flash Cards
What makes a folder a route in the App Router? — Containing a page.tsx file.
What does layout.tsx do across navigations? — Persists without remounting for all nested child routes.
What does loading.tsx wrap the segment in? — An automatic React Suspense boundary.
Default component type in app/? — Server Component, unless “use client” is declared.