Server state vs client state in NextJS - Visual Side-by-Side Comparison

Concept Flow - Server state vs client state

Start: User requests page

↓

Server fetches data

↓

Server sends HTML + data

↓

Client receives HTML + data

↓

Client renders UI with initial data

↓

Client updates state on user actions

↓

Client may fetch new data (server state) asynchronously

↓

UI updates with new server or client state

Shows how data flows from server to client and how client manages its own state after receiving server data.

Execution Sample

NextJS

export default function Page() {
  const [count, setCount] = useState(0);
  const { data } = useQuery('todos');
  return <div>{data.length} todos, count: {count}</div>;
}

A Next.js component showing server-fetched data (todos) and client state (count) together.

Execution Table

Step	Action	Server State	Client State	UI Rendered
1	User requests page	No data yet	No state yet	Loading or empty
2	Server fetches todos	todos = [todo1, todo2]	No state yet	Server prepares HTML with todos count=2
3	Server sends HTML + data	todos = [todo1, todo2]	No state yet	Page shows '2 todos, count: 0' (count default)
4	Client receives HTML + data	todos = [todo1, todo2]	count = 0	Page shows '2 todos, count: 0'
5	User clicks increment	todos = [todo1, todo2]	count = 1	Page updates to '2 todos, count: 1'
6	Client fetches new todos	todos = [todo1, todo2, todo3]	count = 1	Page updates to '3 todos, count: 1'
7	User clicks increment again	todos = [todo1, todo2, todo3]	count = 2	Page updates to '3 todos, count: 2'

💡 User stops interacting; client and server states are synced as needed.

Variable Tracker

Variable	Start	After Step 4	After Step 5	After Step 6	After Step 7
todos	undefined	[todo1, todo2]	[todo1, todo2]	[todo1, todo2, todo3]	[todo1, todo2, todo3]
count	undefined	0	1	1	2

Key Moments - 3 Insights

Why does the UI show 'count: 0' before any user clicks?

Because the client state 'count' is initialized to 0 on first render (see Step 4 in execution_table). Server state 'todos' is fetched separately.

How can client state and server state change independently?

Client state like 'count' changes on user actions without server calls (Step 5), while server state like 'todos' updates only after fetching new data (Step 6).

Why does the UI update when new todos arrive from the server?

Because the client receives updated server state and re-renders UI to reflect new data (Step 6), showing '3 todos' instead of '2 todos'.

Visual Quiz - 3 Questions

Look at the execution_table, what is the value of 'count' at Step 5?

A 1

B 0

C 2

D undefined

💡 Hint

Check the 'Client State' column at Step 5 in the execution_table.

At which step does the server state 'todos' first include 3 items?

A Step 4

B Step 5

C Step 6

D Step 7

💡 Hint

Look at the 'Server State' column in the execution_table to see when todos change.

If the user never clicks increment, what will 'count' be after Step 7?

A 0

B 1

C 2

D undefined

💡 Hint

Refer to variable_tracker for 'count' changes and note user actions in execution_table.

Concept Snapshot

Server state is data fetched and stored on the server, sent to client on page load.
Client state is data managed inside the browser, changing with user actions.
Server state updates require fetching new data; client state updates happen instantly.
UI combines both states to show current info.
In Next.js, server state often comes from data fetching hooks; client state from useState.
Understanding both helps build responsive, data-driven apps.

Full Transcript

This visual trace shows how server state and client state work together in a Next.js app. When a user requests a page, the server fetches data like todos and sends it with the HTML. The client receives this data and initializes its own state, such as a count starting at zero. When the user interacts, like clicking a button, the client state updates immediately without contacting the server. Later, the client can fetch new server data asynchronously, updating the UI again. The execution table tracks each step, showing server and client states and how the UI changes. Variable tracking highlights how todos and count change over time. Key moments clarify common confusions about initial values and independent updates. The quiz tests understanding of state values at different steps. This helps beginners see clearly how server and client states flow and update in a modern web app.

Practice

1. Which of the following best describes server state in Next.js?

easy

A. UI component states like button clicks or form inputs.

B. Temporary data stored only in the browser memory.

C. CSS styles applied to components dynamically.

D. Data fetched from APIs or databases and shared across users.

Solution

1. Step 1: Understand server state meaning

   Server state is data that comes from the server, such as API responses or database queries, and is shared among users.

2. Step 2: Compare with client state

   Client state is local to the browser and changes instantly with user actions, unlike server state.

3. Final Answer:

   Data fetched from APIs or databases and shared across users. -> Option D

4. Quick Check:

   Server state = shared API data [OK]

Hint: Server state = shared data from backend, not local UI [OK]

Common Mistakes:

• Confusing server state with client UI state
• Thinking server state is local to one user
• Mixing server state with CSS or styling

2. Which syntax correctly uses React's useState hook for client state in Next.js?

easy

A. const [count, setCount] = useState(0)

B. const [data, setData] = useState(fetch('/api/data'))

C. const data = await fetch('/api/data')

D. const count = useState(0)

Solution

1. Step 1: Identify correct useState syntax

   useState returns an array with current state and a setter function, so destructuring with [state, setState] is correct.

2. Step 2: Check each option

   const [count, setCount] = useState(0) correctly uses const [count, setCount] = useState(0). const [data, setData] = useState(fetch('/api/data')) wrongly calls fetch inside useState. const data = await fetch('/api/data') is an async fetch, not useState. const count = useState(0) misses destructuring.

3. Final Answer:

   const [count, setCount] = useState(0) -> Option A

4. Quick Check:

   useState returns [state, setter] array [OK]

Hint: useState always destructures [value, setter] array [OK]

Common Mistakes:

• Calling async fetch inside useState
• Not destructuring useState result
• Assigning useState directly to a variable

3. Given this Next.js component, what will be displayed initially?

import { useState, useEffect } from 'react';

export default function Example() {
  const [serverData, setServerData] = useState(null);

  useEffect(() => {
    fetch('/api/data')
      .then(res => res.json())
      .then(data => setServerData(data.message));
  }, []);

  return 
{serverData ?? 'Loading...'}
;
}

medium

A. undefined

B. Loading...

C. null

D. The message from /api/data immediately

Solution

1. Step 1: Check initial state value

   The state serverData starts as null, so the component shows 'Loading...' initially because of the nullish coalescing operator.

2. Step 2: Understand useEffect fetch timing

   The fetch runs after the first render, so the message from the API is not available immediately.

3. Final Answer:

   Loading... -> Option B

4. Quick Check:

   Initial state null shows fallback text [OK]

Hint: Initial null state shows fallback before fetch completes [OK]

Common Mistakes:

• Assuming fetch is synchronous and immediate
• Expecting undefined or null to render as text
• Ignoring useEffect timing

4. Identify the bug in this Next.js component that fetches server state and updates client state:

import { useState, useEffect } from 'react';

export default function DataFetcher() {
  const [data, setData] = useState();

  useEffect(async () => {
    const res = await fetch('/api/data');
    const json = await res.json();
    setData(json);
  }, []);

  return <div>{data.message}</div>;
}

medium

A. useEffect callback cannot be async directly

B. Missing initial state value for useState

C. setData should not be called inside useEffect

D. data.message will always be undefined

Solution

1. Step 1: Check useEffect callback syntax

   React's useEffect callback cannot be async directly; it should call an async function inside.

2. Step 2: Identify correct fix

   Wrap the async fetch logic inside a separate async function inside useEffect, then call it.

3. Final Answer:

   useEffect callback cannot be async directly -> Option A

4. Quick Check:

   Async function inside useEffect, not async callback [OK]

Hint: useEffect callback must be sync; call async function inside [OK]

Common Mistakes:

• Making useEffect callback async directly
• Not handling initial undefined state safely
• Assuming data.message exists before fetch

5. You want to build a Next.js page that shows a list of products fetched from the server and allows users to filter them locally without refetching. Which approach correctly separates server state and client state?

hard

A. Store products in client state only and fetch on every filter change.

B. Fetch products inside useEffect and store in server state for filtering.

C. Fetch products with getServerSideProps and store in client state with useState for filtering.

D. Fetch products with getStaticProps and filter on server on every user input.

Solution

1. Step 1: Understand server state fetching

   Using getServerSideProps fetches data on the server before rendering, providing server state.

2. Step 2: Manage client state for filtering

   Storing the fetched products in useState allows local filtering without refetching, which is client state.

3. Final Answer:

   Fetch products with getServerSideProps and store in client state with useState for filtering. -> Option C

4. Quick Check:

   Server fetch + client filter state = Fetch products with getServerSideProps and store in client state with useState for filtering. [OK]

Hint: Fetch server data once, filter locally with client state [OK]

Common Mistakes:

• Fetching data on every filter change
• Filtering on server for every user input
• Mixing server and client state responsibilities