Client-only modules in NextJS - Step-by-Step Execution

Concept Flow - Client-only modules

Start Next.js App

↓

Import Client-only Module

↓

Check Execution Environment

↓

Server

↓

Skip

↓

Render Page

↓

Display Client-only Features

Next.js checks if code runs on server or client. Client-only modules load and run only in the browser, skipping server rendering.

Execution Sample

NextJS

import dynamic from 'next/dynamic';

const ClientOnlyComponent = dynamic(() => import('./ClientOnlyComponent'), { ssr: false });

export default function Page() {
  return <ClientOnlyComponent />;
}

This code imports a component only on the client side, disabling server-side rendering for it.

Execution Table

Step	Action	Environment	Result	Rendered Output
1	Start app and import dynamic	Server	Module imported, no client-only loaded yet	Page starts rendering
2	Evaluate dynamic import with ssr:false	Server	Skip loading ClientOnlyComponent	Placeholder or empty space rendered
3	Render page on server	Server	Page rendered without ClientOnlyComponent	Page HTML without client-only content
4	Send HTML to browser	Client	Browser receives HTML	Page visible but client-only part missing
5	Browser runs JS, triggers dynamic import	Client	ClientOnlyComponent loaded and executed	Client-only content appears
6	User sees full page with client-only features	Client	Client-only module active	Full interactive page displayed
7	End	-	-	Execution complete

💡 Client-only module is not loaded on server (ssr:false), loads only in browser after initial HTML render

Variable Tracker

Variable	Start	After Step 2	After Step 5	Final
ClientOnlyComponent	undefined	undefined (skipped on server)	Loaded component	Loaded component

Key Moments - 2 Insights

Why does the ClientOnlyComponent not appear in the server-rendered HTML?

Because the dynamic import uses { ssr: false }, Next.js skips loading this module on the server as shown in execution_table step 2, so it doesn't render on the server.

When does the ClientOnlyComponent actually load and render?

It loads only in the browser after the initial HTML is sent, as shown in execution_table step 5, when the client runs the JavaScript and dynamically imports the module.

Visual Quiz - 3 Questions

Look at the execution_table, at which step does the ClientOnlyComponent first become loaded?

A Step 5

B Step 3

C Step 2

D Step 1

💡 Hint

Check the 'Result' column for when ClientOnlyComponent is 'Loaded component'

According to variable_tracker, what is the value of ClientOnlyComponent after step 2?

A Loaded component

B null

C undefined (skipped on server)

D Error

💡 Hint

Look at the 'After Step 2' column for ClientOnlyComponent in variable_tracker

If we remove { ssr: false } from dynamic import, what changes in the execution_table?

A ClientOnlyComponent never loads

B ClientOnlyComponent loads on server and client

C ClientOnlyComponent loads only on client as before

D Page fails to render

💡 Hint

Removing ssr:false means server tries to load the module, check step 2 behavior

Concept Snapshot

Client-only modules in Next.js load only in the browser.
Use dynamic import with { ssr: false } to skip server rendering.
Server renders page without client-only parts.
Client loads and runs module after initial HTML.
This avoids server errors from browser-only code.

Full Transcript

In Next.js, client-only modules are loaded only in the browser, not on the server. This is done by using dynamic imports with the option ssr:false. When the app starts, Next.js imports modules but skips client-only ones during server rendering. The server sends HTML without the client-only parts. When the browser receives the page, it runs JavaScript that dynamically loads and runs the client-only modules. This way, browser-specific code does not break server rendering. The execution table shows these steps clearly, with the client-only component undefined on the server and loaded on the client. The variable tracker confirms the component is undefined on the server and loaded later in the browser. This pattern helps keep Next.js apps stable and interactive.

Practice

1. What is the main reason to use client-only modules in Next.js?

easy

A. They run only in the browser, avoiding server errors with browser APIs.

B. They improve server-side rendering speed by running on the server.

C. They allow using Node.js modules on the server.

D. They enable static site generation without JavaScript.

Solution

1. Step 1: Understand client-only module purpose

   Client-only modules run only in the browser to avoid errors from browser-specific APIs on the server.

2. Step 2: Compare options

   They run only in the browser, avoiding server errors with browser APIs. correctly states this purpose. Options B, C, and D describe unrelated or incorrect behaviors.

3. Final Answer:

   They run only in the browser, avoiding server errors with browser APIs. -> Option A

4. Quick Check:

   Client-only modules = browser-only code [OK]

Hint: Client-only means browser-only to avoid server API errors [OK]

Common Mistakes:

• Thinking client-only modules run on the server
• Confusing client-only with static generation
• Assuming client-only modules improve server speed

2. Which syntax correctly imports a client-only module named MyComponent using Next.js dynamic import?

easy

A. const MyComponent = require('./MyComponent');

B. import dynamic from 'next/dynamic'; const MyComponent = dynamic(() => import('./MyComponent'), { ssr: false });

C. import MyComponent from './MyComponent';

D. import dynamic from 'next/dynamic'; const MyComponent = dynamic(() => import('./MyComponent'));

Solution

1. Step 1: Recall dynamic import with ssr: false

   To load client-only modules, Next.js requires dynamic import with { ssr: false } to disable server-side rendering.

2. Step 2: Analyze options

   import dynamic from 'next/dynamic'; const MyComponent = dynamic(() => import('./MyComponent'), { ssr: false }); uses dynamic import with ssr: false correctly. import MyComponent from './MyComponent'; is a normal import (runs on server too). const MyComponent = require('./MyComponent'); uses require, not recommended in Next.js. import dynamic from 'next/dynamic'; const MyComponent = dynamic(() => import('./MyComponent')); misses ssr: false, so it runs on server.

3. Final Answer:

   import dynamic from 'next/dynamic'; const MyComponent = dynamic(() => import('./MyComponent'), { ssr: false }); -> Option B

4. Quick Check:

   Use dynamic + ssr: false for client-only imports [OK]

Hint: Use dynamic import with ssr: false for client-only modules [OK]

Common Mistakes:

• Forgetting { ssr: false } disables server rendering
• Using normal import for client-only modules
• Using require instead of import

3. Given this code snippet in Next.js, what will be the rendered output?

import dynamic from 'next/dynamic';
const ClientOnly = dynamic(() => import('./ClientOnlyComponent'), { ssr: false });

export default function Page() {
  return (
    

      
Welcome
      
    
  );
}

Assuming ClientOnlyComponent renders <p>Loaded on client</p>.

medium

A. WelcomeLoaded on client

B. Welcome

C. WelcomeLoading...

D. Error: ClientOnlyComponent cannot be rendered on server

Solution

1. Step 1: Understand dynamic import with ssr: false

   The component ClientOnly loads only on the client, so server renders without it initially, showing a loading placeholder.

2. Step 2: Predict final render output

   Before hydration, the placeholder Loading... is shown. After hydration, ClientOnlyComponent renders <p>Loaded on client</p>. The initial render output includes the heading and loading placeholder.

3. Final Answer:

   <div><h1>Welcome</h1><p>Loading...</p></div> -> Option C

4. Quick Check:

   Client-only modules show loading placeholder on server render [OK]

Hint: Client-only components show loading placeholder before hydration [OK]

Common Mistakes:

• Expecting client-only content on server render
• Assuming error occurs without server rendering
• Thinking loading placeholder always shows

4. You wrote this code to import a client-only module:

import dynamic from 'next/dynamic';
const Widget = dynamic(() => import('./Widget'));

export default function Home() {
  return ;
}

What is the main problem here?

medium

A. Missing { ssr: false } causes server to try rendering Widget, which may fail.

B. Dynamic import syntax is incorrect; should use require instead.

C. Widget component must be imported normally, not dynamically.

D. You must wrap Widget in a Suspense component for dynamic imports.

Solution

1. Step 1: Check dynamic import options

   The code uses dynamic import but omits { ssr: false }, so Next.js tries to render Widget on the server.

2. Step 2: Understand consequences

   If Widget uses browser-only APIs, server rendering will fail or cause errors. Adding { ssr: false } prevents server rendering.

3. Final Answer:

   Missing { ssr: false } causes server to try rendering Widget, which may fail. -> Option A

4. Quick Check:

   Always add ssr: false for client-only modules [OK]

Hint: Add { ssr: false } to disable server rendering for client-only modules [OK]

Common Mistakes:

• Forgetting ssr: false option
• Thinking dynamic import syntax is wrong without require
• Assuming Suspense is mandatory for dynamic imports

5. You want to use a browser-only API inside a Next.js component, but only on the client side. Which approach correctly ensures this without server errors?

import dynamic from 'next/dynamic';

const BrowserOnly = dynamic(() => import('./BrowserOnlyComponent'), { ssr: false });

export default function Page() {
  return (
    

      
Client-only Example
      
    
  );
}

What else should you do inside BrowserOnlyComponent to safely use browser APIs?

hard

A. Wrap browser API calls inside a try-catch in the component body.

B. Call browser APIs directly in the component body without hooks.

C. Use getServerSideProps to fetch browser API data on server.

D. Use React's useEffect hook to run browser API code after component mounts.

Solution

1. Step 1: Understand client-only import

   Dynamic import with { ssr: false } ensures the component loads only on the client, avoiding server errors.

2. Step 2: Use useEffect for browser APIs

   Inside the component, browser APIs should be called inside useEffect to run after mounting, ensuring the DOM and window objects exist.

3. Final Answer:

   Use React's useEffect hook to run browser API code after component mounts. -> Option D

4. Quick Check:

   Browser APIs inside useEffect = safe client use [OK]

Hint: Put browser API calls inside useEffect to run after mount [OK]

Common Mistakes:

• Calling browser APIs directly in render causing errors
• Trying to use browser APIs on server via getServerSideProps
• Relying on try-catch instead of proper lifecycle hooks