Next.js · Beginner interview

Next.js is a React framework that adds the pieces a plain React SPA lacks: file-based routing, server-side rendering and static generation, server components, data fetching conventions, API/route handlers, image and font optimization, and a production build pipeline. You use it when you want better performance and SEO than a client-only app and don't want to assemble routing, SSR, and bundling yourself.

The Pages Router (pages/) is the original system: file-based routes with getServerSideProps/getStaticProps for data. The App Router (app/) is the newer model built on React Server Components, with nested layouts, server components by default, streaming, and colocated loading/error files. New projects use the App Router; the Pages Router is still supported for existing apps.

Routes are defined by the folder structure rather than a config. In the App Router, each folder under app/ is a URL segment and a page.tsx in it makes that segment routable; special files like layout.tsx, loading.tsx, and error.tsx add shared UI and states. So app/blog/page.tsx serves /blog with no router setup.

You name a folder with square brackets, like app/blog/[slug]/page.tsx, which matches /blog/anything. The segment value arrives via the params prop (a promise you await in newer versions). You can also use [...slug] for catch-all routes and [[...slug]] for optional catch-alls.

// app/blog/[slug]/page.tsx
export default async function Page({ params }) {
  const { slug } = await params;
  return <h1>{slug}</h1>;
}

Use the Link component for declarative navigation — it does client-side transitions and prefetches the route. For programmatic navigation in a client component, use the useRouter hook from next/navigation and call router.push(). Plain anchor tags work but force a full reload, so prefer Link.

import Link from "next/link";
<Link href="/blog/hello">Read</Link>

A layout.tsx wraps the pages in its folder and nested folders, providing shared UI like a header or sidebar that persists across navigations without re-rendering. The root layout (app/layout.tsx) is required and defines the html and body. Layouts nest, so you can have a section layout inside the root one.

In the App Router, components are Server Components by default: they render on the server, can fetch data and access server resources directly, and ship no JavaScript to the browser. A Client Component, marked with 'use client' at the top, runs in the browser and can use state, effects, and event handlers. You keep most of the tree on the server and opt into client components only where you need interactivity.

SSR renders HTML on the server per request (fresh, slightly slower); SSG renders at build time and serves static HTML (fast, cacheable); CSR renders in the browser after loading JS. In the App Router, Next statically renders routes by default and switches to dynamic (per-request) rendering when you use dynamic data or APIs, with ISR letting static pages revalidate periodically. You choose mostly through how you fetch data, not explicit flags.

Export a metadata object (or a generateMetadata function for dynamic values) from a layout or page, and Next renders the appropriate head tags. This replaces manually managing the document head and supports titles, descriptions, Open Graph, and more, merging across nested layouts.

export const metadata = { title: "Blog", description: "..." };

Just make the component async and await your data directly — call fetch or your database in the component body, with no useEffect or client state. Because it runs on the server, the data never ships as client JS and there's no loading flash for the initial render. Next also augments fetch with caching and revalidation.

export default async function Page() {
  const posts = await fetch(api).then(r => r.json());
  return <List posts={posts} />;
}

loading.tsx provides an instant loading UI for a route segment while its server component streams in — Next wraps the segment in a Suspense boundary automatically. error.tsx is a client component that catches rendering errors in that segment and shows a fallback with a retry, acting as an error boundary. They let you handle loading and error states per route with files instead of manual boilerplate.

Variables in .env are available server-side via process.env. To expose one to the browser you must prefix it with NEXT_PUBLIC_, which inlines it into the client bundle at build time — so never put secrets there. Server-only secrets stay unprefixed and are never sent to the client.