Vishal's Blog

Understanding Client-Side and Server-Side Rendering in Next.js App Directory

Vishal's photo
Vishal
·

8 min read

Next.js has evolved significantly over time, and one of the major changes is the introduction of the App Directory (app/). This new directory structure brings powerful features such as Server-Side Rendering (SSR) and Client-Side Rendering (CSR), along with Layouts and Dynamic Routing to help manage how your application behaves on the server and client.

However, with all this flexibility comes complexity, especially when it comes to determining which parts of your app are rendered on the server and which parts on the client. In this article, we’ll explore how Next.js handles SSR and CSR in the App Directory, focusing on how layouts, pages, and the "use client" directive work together to control rendering behavior.

1. The Basics of Client-Side Rendering (CSR) and Server-Side Rendering (SSR)

Before diving into Next.js specifics, let's define CSR and SSR:

  • Client-Side Rendering (CSR): In CSR, the rendering of the content is done entirely in the browser. The page is sent from the server as a bare-bones HTML file (often a minimal skeleton) and JavaScript. The JavaScript code executes in the browser and fetches and renders the content dynamically.

  • Server-Side Rendering (SSR): With SSR, the server generates the HTML content of the page at the time of the request, sends it to the browser, and the content is fully rendered on the server before being delivered to the client.

Next.js supports both SSR and CSR, and its new App Directory structure makes it possible to control rendering behavior more finely through Layouts and Pages.

2. Understanding the App Directory Structure

In Next.js, you can now organize your app using the app/ directory. The basic structure looks like this:

├─ app
│  ├─ components
│  ├─ error.tsx
│  ├─ layout.tsx
│  ├─ page.tsx
│  ├─ settings
│  │  ├─ layout.tsx
│  │  └─ page.tsx
│  └─ dashboard
│     ├─ layout.tsx
│     └─ page.tsx
├─ public
├─ styles
└─ next.config.ts

  • app/layout.tsx: This is the global layout that wraps your entire application and defines common elements such as headers, footers, and context providers (e.g., Redux, theme providers).

  • app/page.tsx: This is the root page for the base URL (/). It is often used to render the main content of the homepage.

  • app/settings/layout.tsx and app/settings/page.tsx: These are the layout and page for the /settings route. You can create similar structures for other sections of your app.

3. The Role of Layouts in Controlling Rendering Behavior

In the App Directory, Layouts play a critical role in determining how your pages are rendered. A layout can either wrap pages in client-side logic or leave them server-rendered.

How Layouts Impact Rendering

  1. Global Layout (app/layout.tsx): This layout wraps everything under the root URL (/) and applies globally across all routes unless overridden by a child layout. It can provide client-side features (like Redux state management) or shared UI elements (e.g., navigation bars, footers).

    • If this layout wraps its children in a ClientProvider, all pages rendered within this layout will be client-side rendered (CSR).

  2. Nested Layouts (e.g., app/settings/layout.tsx): If you have a layout inside a nested route (like /settings), this layout will override the global layout for that specific section of your app. If the nested layout includes client-side logic (like ClientProvider), then the pages under /settings will also be rendered client-side. If not, they will be server-rendered.

4. The "use client" Directive for Client-Side Components

In Next.js, you can explicitly mark individual components or pages as client-side rendered (CSR) by adding the "use client" directive at the top of the file.

For example, you might have a page under the /settings route, but you want to make it a client-side component to use React state, hooks, or other client-specific features. To do this, you add the "use client" directive:

tsxCopy// app/settings/page.tsx
"use client";  // Mark this as a client-side component
import { useState } from "react";

export default function SettingsPage() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <h1>Settings</h1>
      <button onClick={() => setCount(count + 1)}>Increment</button>
      <p>Current Count: {count}</p>
    </div>
  );
}

By adding "use client", Next.js will treat this page as client-side rendered, meaning it will be rendered in the browser and not on the server.

Why Use "use client"?

  • When you need client-side interactivity (such as React hooks, state management, or use of browser APIs), you explicitly mark those components with "use client".

  • This ensures that Next.js does not attempt to render these components on the server, avoiding any mismatch errors between the server-rendered HTML and client-rendered content.

5. Examples of SSR vs. CSR in Next.js App Directory

Let’s take a look at practical examples of how SSR and CSR are determined based on layout configuration.

Example 1: Server-Side Rendered (SSR)

Here, we create a settings page where no client-side logic is required.

tsxCopy// app/settings/layout.tsx
export default function SettingsLayout({ children }) {
  return <div>{children}</div>;  // No ClientProvider here, so this page will be SSR
}

// app/settings/page.tsx
export default function SettingsPage() {
  return <div>Manage your settings here.</div>;
}

Since SettingsLayout doesn’t include ClientProvider, the SettingsPage will be server-side rendered.

Example 2: Client-Side Rendered (CSR)

Now, let’s create a dashboard page with client-side interactivity like React hooks and event handlers.

tsxCopy// app/dashboard/layout.tsx
import ClientProvider from "@/app/providers/client-provider";  // ClientProvider here
export default function DashboardLayout({ children }) {
  return <div><ClientProvider>{children}</ClientProvider></div>;
}

// app/dashboard/page.tsx
"use client";  // Marking this as a client-side component
import { useState } from "react";

export default function DashboardPage() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <h1>Dashboard</h1>
      <p>Current count: {count}</p>
      <button onClick={() => setCount(count + 1)}>Increment</button>
    </div>
  );
}

In this case:

  • DashboardLayout wraps the page in ClientProvider, making it a client-side rendered section.

  • DashboardPage is explicitly marked as a client-side component with "use client", enabling client-side features.

Example 3: Mixed Rendering

You can also have a mix of both SSR and CSR in the same app by using layouts and "use client" together.

Key Points to Understand:

  1. Global Layout (app/layout.tsx): This layout wraps your entire application and is rendered when you visit the base URL (/). It’s the first layout that Next.js uses, and if you include shared components like a header or a footer here, they will be part of every page on your site unless explicitly overridden by a nested layout. So, for example, if you want a global header or footer to appear on all pages (including /settings, /dashboard, etc.), you would put them in app/layout.tsx.

  2. Nested Layouts (e.g., app/settings/layout.tsx): These layouts are specific to the route where they are defined. So, if you have a layout under a specific route like /settings (app/settings/layout.tsx), it will override the global layout only within that route. However, if you want to use the global header from app/layout.tsx inside the /settings route, you can still include it in the app/settings/layout.tsx.

  3. The Hierarchical Nature of Layouts:

    • When you visit a page like /settings, Next.js will first check for a layout in app/settings/layout.tsx. If it exists, it will be used.

    • If there’s no layout in /settings, Next.js will fall back to the global layout (app/layout.tsx).

  4. How app/layout.tsx and nested layouts interact:

    • Global Layout: Can contain things like a header, footer, context providers, etc., that you want to apply globally.

    • Nested Layouts: You can still include shared elements from the global layout. For instance, even though app/settings/layout.tsx is specific to the settings route, you can still include the global header inside app/settings/layout.tsx.

Example to Explain:

1. Global Layout with Header/Footer (app/layout.tsx)

tsxCopy// app/layout.tsx
import { Navbar } from "@/app/components/layout/navbar"; // Global header
import Footer from "@/app/components/layout/footer"; // Global footer
import ClientProvider from "@/app/providers/client-provider"; // Client-side state management

export default function RootLayout({ children }) {
  return (
    <html lang="en">
      <body>
        <ClientProvider>
          <Navbar /> {/* Global header */}
          <div>{children}</div> {/* Page content */}
          <Footer /> {/* Global footer */}
        </ClientProvider>
      </body>
    </html>
  );
}

In this setup, Navbar and Footer are present on every page by default because they’re inside the global layout (app/layout.tsx).

2. Settings Layout with Global Header (app/settings/layout.tsx)

Now, you have a route for /settings. Even though you have a separate layout for /settings, you can still include the global header and add settings-specific components:

tsxCopy// app/settings/layout.tsx
import { Navbar } from "@/app/components/layout/navbar"; // Reusing global header
import ClientProvider from "@/app/providers/client-provider"; // Can wrap in ClientProvider if needed

export default function SettingsLayout({ children }) {
  return (
    <div>
      <Navbar /> {/* Global header */}
      <div>{children}</div> {/* Settings page content */}
    </div>
  );
}

Even though /settings has its own layout, the Navbar from the global layout is still included, so you don’t lose the header or other shared components. You can even add more specific elements related to the settings page here.

3. How Does This Affect /dashboard or Other Routes?

Let’s say you also have a /dashboard route:

tsxCopy// app/dashboard/layout.tsx
import { Navbar } from "@/app/components/layout/navbar"; // Global header
import ClientProvider from "@/app/providers/client-provider"; // Optional if CSR is needed

export default function DashboardLayout({ children }) {
  return (
    <div>
      <Navbar /> {/* Global header */}
      <div>{children}</div> {/* Dashboard page content */}
    </div>
  );
}

The global header is also available here because it’s included inside the DashboardLayout.

6. Conclusion: Managing SSR and CSR in Next.js

Next.js gives you powerful tools to control rendering behavior at a granular level using layouts, pages, and the "use client" directive. The App Directory structure allows for better organization of your app and more control over SSR and CSR:

  • Layouts define whether a section of the app should be rendered on the server or client.

  • Pages are rendered either SSR or CSR depending on their location within the app and the layout wrapping them.

  • The "use client" directive lets you mark specific components or pages as client-side components when interactivity is needed.

By understanding how to leverage these features, you can create applications that are efficient, flexible, and optimized for both server-side and client-side rendering.

Next.jsWeb DevelopmentReactSSRNext.js 13.2Frontend Development