Week 17: App Router Data Fetching, Layouts & Streaming

1. Nested Layouts

A layout.tsx file wraps every page and layout nested inside its folder — and critically, a layout doesn't re-render when navigating between its child pages. Navigating from /dashboard/overview to /dashboard/settings re-renders only the changing part; the shared dashboard/layout.tsx around them stays mounted.

export default function DashboardLayout({ children }: { children: React.ReactNode }) {
  return (
    <div className="dashboard">
      <DashboardSidebar /> {/* stays mounted across dashboard/* navigations */}
      <main>{children}</main>
    </div>
  );
}

This matters for data fetching specifically: if DashboardSidebar fetches the current user inside the layout, that fetch runs once when the layout first mounts, not again on every navigation between dashboard sub-pages — a meaningfully different (and better) default than Week 6's <Outlet /> pattern, where re-fetching on every route change required deliberate caching (Week 8) to avoid.

2. loading.tsx & Automatic Suspense

A file named loading.tsx in any route folder is automatically wrapped around that route's page.tsx as a Suspense fallback — no manual <Suspense> JSX required, unlike Week 12's hand-wired version.

export default function Loading() {
  return <ProductListSkeleton />;
}

Next.js effectively wraps app/products/page.tsx in <Suspense fallback={''}> automatically. While ProductsPage's await getProducts() (Week 16) is pending, Loading shows instead — the same underlying Suspense mechanism, now a file-naming convention instead of explicit JSX.

3. Streaming with Suspense Boundaries

A page-level loading.tsx blocks the entire page until its slowest fetch resolves. If a page has one fast piece of data and one genuinely slow one, wrapping just the slow piece in its own Suspense lets the fast content stream to the browser immediately, with the slow section's fallback showing only where that section will eventually appear.

import { Suspense } from 'react';

export default async function ProductDetailPage({ params }: { params: { productId: string } }) {
  const product = await getProduct(params.productId); // fast -- awaited directly

  return (
    <div>
      <h1>{product.name}</h1> {/* streams to the browser immediately */}

      <Suspense fallback={<ReviewsSkeleton />}>
        <ProductReviews productId={product.id} /> {/* slow -- streams in separately, later */}
      </Suspense>
    </div>
  );
}

async function ProductReviews({ productId }: { productId: string }) {
  const reviews = await getReviews(productId); // a slow, separate fetch
  return <ul>{reviews.map((r: Review) => <li key={r.id}>{r.text}</li>)}</ul>;
}

The product name appears the instant its own fast fetch resolves; the reviews section's skeleton shows in place until getReviews finishes, at which point that piece of HTML streams in and swaps the skeleton out — all in a single page load, no client-side JavaScript request involved. This is the same ErrorBoundary + Suspense composition from Week 12, now streaming real server-rendered HTML instead of client-fetched data.

4. Static Generation with generateStaticParams

For dynamic routes whose full set of possible values is known ahead of time (a blog's slugs, a fixed product catalog), Next.js can render every page at build time instead of on every request — the fastest possible option, since there's no server work left to do when a real user requests the page.

export async function generateStaticParams() {
  const posts = await getAllPostSlugs(); // e.g. [{ slug: 'hello-world' }, { slug: 'react-tips' }]
  return posts; // Next.js pre-renders one static page per entry, at build time
}

export default async function BlogPostPage({ params }: { params: { slug: string } }) {
  const post = await getPostBySlug(params.slug);
  return <article>{post.content}</article>;
}

generateStaticParams tells Next.js the complete list of slug values to pre-render during next build — the resulting HTML for each is generated once and served identically to every visitor, like a plain static file, until the next deploy.

5. SSR vs. SSG vs. Client Rendering — When to Use Each

Three genuinely different rendering strategies, each right for a different shape of content:

• SSG (Static Site Generation) — rendered once at build time. Fastest possible response, but content is only as fresh as the last deploy. Right for: blog posts, marketing pages, documentation, a product catalog that changes infrequently.
• SSR (Server-Side Rendering) — rendered fresh on every request, on the server (the default for a Server Component without generateStaticParams). Right for: personalized content, data that must always be current, pages depending on request-specific data like cookies.
• Client Rendering — a Client Component (Week 16) fetching with useQuery (Week 8) after the page loads. Right for: highly interactive, frequently-changing data behind an already-loaded shell — a live dashboard, a chat window, anything where Week 8–9's caching and mutation behavior is the actual point.

These aren't mutually exclusive within one app, or even one page — Section 3's example mixes an awaited server fetch (effectively SSR for that piece) with a streamed, separately-loading section, and a real page might further nest a Client Component using useMutation for a comment form. Choosing the right strategy per piece of content, not per whole app, is the actual skill.

6. Hands-on Exercise

7. Knowledge Check

Four quick questions. Expand each to check your answer.