## The Big Shift: Server vs Client Components If you've used [React](/courses/reactjs) before [Next.js](/courses/nextjs), your brain probably learned this rule: ```text React component ↓ Runs in the browser ``` Then [Next.js App Router](/courses/nextjs) shows up and says: > "Yeah... we're changing that." 😎 In the Next.js App Router, components are **[Server Components](/courses/nextjs) by default**. That means when you create: ```jsx export default function Page() { return

Hello Next.js

} ``` you've created a Server Component without doing anything special. No: ```jsx "use server" ``` required. No configuration. Server is the default. This is one of the biggest differences between traditional client-heavy [React](/courses/reactjs) applications and modern [Next.js](/courses/nextjs). --- # Why Does Next.js Use Server Components? Traditionally, a lot of React code gets shipped to the browser. The browser then has to: ```text Download JavaScript ↓ Parse JavaScript ↓ Execute JavaScript ↓ Render UI ``` The more [JavaScript](/courses/javascript) you send, the more work the user's device has to do. [Server Components](/courses/nextjs) let Next.js move some of that work to the server. Instead of shipping every component's [JavaScript](/courses/javascript) to the browser, Next.js can render Server Components on the server and send their rendered result to the client. Conceptually: ```text Server Component ↓ Runs on server ↓ React creates RSC payload ↓ Next.js sends result to browser ↓ Browser displays UI ``` This can mean: - Less client-side JavaScript - Smaller bundles - Direct server-side data fetching - Secure access to backend resources - Better separation between server and browser responsibilities --- > **Definition: React Server Component** > > A React component that runs in the server environment instead of the browser. Its component module code isn't included in the browser's client JavaScript bundle. React sends its rendered result through the React Server Component payload, which Next.js uses to build and update the UI. --- # Two Environments, One Application The easiest way to understand Server and Client Components is to imagine your application living in two worlds. ```text SERVER ├── Database ├── File system ├── Secret environment variables ├── Backend services └── Server Components ``` and: ```text BROWSER ├── window ├── document ├── Click events ├── Local state └── Client Components ``` Different jobs belong in different environments. The server is great for: ```text Fetching data Reading databases Using secrets Heavy backend logic ``` The browser is great for: ```text Clicks Typing Animations State Browser APIs ``` Next.js lets both worlds work together. --- # Server Components Server Components are the default in the App Router. Example: ```jsx export default function Page() { return (

I'm a Server Component

) } ``` Nothing special needed. --- ## What Can Server Components Do? Server Components are great for tasks that belong on the server. They can: - Fetch data - Query databases - Read files - Access backend services - Use secret environment variables - Use `async/await` while rendering - Import server-only libraries - Perform expensive server-side work For example: ```jsx async function getUsers() { const response = await fetch( "https://api.example.com/users" ) return response.json() } export default async function UsersPage() { const users = await getUsers() return (

{user.name}

) } ``` Notice something? No: ```js useEffect() ``` No: ```js useState() ``` No: ```text Load page ↓ Run effect ↓ Fetch data ↓ Set state ↓ Render again ``` The component can fetch its data directly while rendering on the server. That's a huge mental shift. --- # Server Components Can Access the Database Directly This is one of the coolest benefits. In a traditional frontend application, you might have: ```text React Component ↓ HTTP Request ↓ Express API ↓ Database ``` With a Server Component, you can sometimes skip the internal API layer: ```text Server Component ↓ Database ``` For example: ```jsx import { db } from "@/lib/db" export default async function UsersPage() { const users = await db.user.findMany() return (

{user.name}

) } ``` The database query runs on the server. The browser never receives your database credentials. Very nice. 🔥 --- # Server Components and Secret API Keys Suppose you need a private API key: ```env SECRET_API_KEY=super-secret-key ``` A Server Component can use it safely in server-side code: ```jsx async function getUsers() { const response = await fetch( "https://api.example.com/users", { headers: { Authorization: `Bearer ${process.env.SECRET_API_KEY}`, }, } ) return response.json() } ``` Because this code stays in the server environment, the secret itself isn't shipped inside the browser's JavaScript bundle. But remember: > **A secret is only safe if you don't intentionally send it to the client afterward.** This would obviously be terrible: ```jsx ``` Next.js cannot protect you from voluntarily mailing your secret to the browser. 😭 --- # What Server Components Cannot Do Server Components don't run inside the browser. So they cannot directly use browser-only features such as: ```js window ``` ```js document ``` ```js localStorage ``` They also cannot use client-side state and lifecycle [hooks](/courses/reactjs/chapter-11-advanced-hooks-useref-usereducer-usememo-usecallback) such as: ```js useState() ``` ```js useEffect() ``` And you can't attach interactive event handlers directly inside a Server Component like: ```jsx ``` Why? Because: ```text onClick ``` needs JavaScript running in the browser. The Server Component itself isn't part of the client-side JavaScript module graph. --- ## Server Component Limitation Example This won't work as a Server Component: ```jsx import { useState } from "react" export default function Counter() { const [count, setCount] = useState(0) return ( ) } ``` Next.js will tell you that this functionality requires a **Client Component**. And that's where: ```jsx "use client" ``` enters the story. --- # Client Components A Client Component is a component that needs client-side React features. To create one, add: ```jsx "use client" ``` at the very top of the file. Example: ```jsx "use client" import { useState } from "react" export default function Counter() { const [count, setCount] = useState(0) return (

Count: {count}

) } ``` Now the component can use: ```js useState() ``` and: ```js onClick ``` because its JavaScript becomes part of the client-side application. --- # What Does `"use client"` Actually Mean? This is important. A lot of beginners think: ```jsx "use client" ``` means: > "This component only renders in the browser." That's not quite right. `"use client"` defines a **boundary between the server and client module graphs**. Once a file has: ```jsx "use client" ``` that file becomes a Client Component entry point. Its imports and dependencies become part of the client-side module graph as needed. Conceptually: ```text Server Components ↓ ----------------------- "use client" ----------------------- ↓ Client Components ``` Think of `"use client"` as saying: > "From this point, this component needs browser-side JavaScript." --- > **Interview Highlight** > > **Q: What does `"use client"` actually do?** > > It creates a client boundary in the React module graph. The component can use browser-side React features such as state, effects, event handlers, and browser APIs, and its required JavaScript becomes part of the client bundle. --- # Client Components Can Still Be Pre-Rendered Here's another common misunderstanding: ```text Client Component = Browser-only rendering ``` Not necessarily. On the initial page load, Next.js can use Client Components as part of the server-generated initial [HTML](/courses/html). Then the browser downloads their JavaScript and **hydrates** them. Conceptually: ```text Server ↓ Generate initial HTML ↓ Browser displays page ↓ Download Client Component JS ↓ Hydration ↓ Component becomes interactive ``` So a Client Component can participate in the initial server-rendered output while still needing JavaScript in the browser for interactivity. --- # What is Hydration? Hydration is the process where React attaches client-side JavaScript behavior to server-generated [HTML](/courses/html). Imagine the server sends: ```html ``` The browser can already display the button. But initially, HTML alone doesn't know what this means: ```js setCount(count + 1) ``` React's client-side JavaScript loads and connects the behavior to the existing UI. That's hydration. Conceptually: ```text Server HTML + Client JavaScript = Interactive React UI ``` --- # When Should You Use a Client Component? Use a Client Component when you need features such as: - `useState` - `useEffect` - Event handlers - Browser APIs - `localStorage` - `sessionStorage` - `window` - `document` - Interactive forms - Modals - Dropdowns - Interactive menus - Browser-side libraries Examples: ```jsx onClick={} ``` ```jsx onChange={} ``` ```jsx useState() ``` ```jsx useEffect() ``` usually mean: > "Yep, this part probably needs to be a Client Component." --- # The Golden Rule: Keep `"use client"` Small One of the easiest beginner mistakes is putting: ```jsx "use client" ``` at the top of a giant page because one tiny button needs `onClick`. Technically? It may work. Architecturally? You've just invited a lot more code to the client-side party than necessary. 😭 Instead, keep Server Components as high as possible and push interactivity into smaller Client Components. --- ## Bad Composition Imagine: ```text Product Page ├── Product Information ├── Product Description ├── Reviews └── Add To Cart Button ``` Only the button needs interactivity. But you do: ```jsx "use client" ``` inside the entire: ```text page.jsx ``` Now a much larger section of your component tree belongs to the client boundary. Conceptually: ```text ❌ BAD ProductPage (Client) ├── ProductInfo ├── Description ├── Reviews └── AddToCartButton ``` --- ## Better Composition Keep the page on the server: ```text ✅ BETTER ProductPage (Server) ├── ProductInfo (Server) ├── Description (Server) ├── Reviews (Server) └── AddToCartButton (Client) ``` Only the interactive piece needs client-side JavaScript. That's the pattern you should aim for. --- # Example: Server Page + Client Button Server Component: ```jsx import AddToCartButton from "@/components/AddToCartButton" async function getProducts() { const response = await fetch( "https://api.example.com/products" ) return response.json() } export default async function ProductsPage() { const products = await getProducts() return (

{products.map(product => (

{product.name}

${product.price}

))}

) } ``` Client Component: ```jsx "use client" import { useState } from "react" export default function AddToCartButton({ productId }) { const [added, setAdded] = useState(false) function handleAddToCart() { setAdded(true) console.log( "Adding product:", productId ) } return ( ) } ``` Now: ```text Product data ↓ Rendered on server ``` while: ```text Add To Cart interaction ↓ Runs in browser ``` Each environment does what it's best at. --- # Think in Islands of Interactivity A useful mental model is: > **Make most of the page server-rendered and create small islands of client-side interactivity where needed.** For example: ```text Product Page SERVER │ ├── Header SERVER ├── Product Details SERVER ├── Reviews SERVER │ ├── Quantity Picker CLIENT ├── Add To Cart CLIENT │ └── Footer SERVER ``` You don't need to choose: ```text Entire app = Server ``` or: ```text Entire app = Client ``` You can mix them. That's the whole point. --- # Passing Data from Server to Client Server Components can render Client Components and pass data to them using props. Example: ```jsx import UserCard from "./UserCard" export default async function Page() { const user = await getUser() return ( ) } ``` Then the Client Component receives it normally: ```jsx "use client" export default function UserCard({ user }) { return (

{user.name}

) } ``` Easy. But there's an important rule. --- # Props Crossing the Boundary Must Be Serializable Data crossing from a Server Component into a Client Component generally needs to be serializable by React. Common values such as these are fine: ```js "hello" ``` ```js 42 ``` ```js true ``` ```js { id: 1, name: "Asif" } ``` ```js [ { id: 1 }, { id: 2 } ] ``` But arbitrary runtime objects or [functions](/javascript/functions-in-javascript) can't simply be passed across the boundary like normal data. For example, this is not a normal serializable prop: ```jsx { console.log("clicked") }} /> ``` because that [function](/javascript/functions-in-javascript) exists in the server environment and can't magically be copied into the browser. There are special React/Next.js mechanisms such as **Server Functions / Server Actions** that can cross this boundary in controlled ways, but ordinary props should be thought of as serializable data. We'll learn Server Actions later. --- # A Better Data-Passing Example Suppose your database returns a huge user object: ```js { id, name, email, passwordHash, internalFlags, createdAt, ... } ``` You don't necessarily want to hand the entire thing to a Client Component. Instead: ```jsx const user = await getUser() return ( ) ``` Now only the data the browser actually needs crosses the boundary. This is good for: - Security - Performance - Clear architecture - Smaller payloads Never expose data just because: > "Well... it was already in the object." 💀 --- # Can a Client Component Import a Server Component? Here's where composition gets interesting. You should not directly import a Server Component into a Client Component as though it were part of the client module graph. For example, avoid thinking like this: ```text Client Component ↓ import Server Component ``` because once you're inside the client boundary, imported modules become part of that client-side graph. Instead, Server Components can compose Client Components and pass server-rendered UI through props such as `children`. Conceptually: ```text Server Component ├── Client Component │ └── Server-rendered children ``` This allows server and client UI to work together without turning everything into client-side code. --- # Server Components Can Render Client Components This is completely normal: ```jsx // Server Component import Counter from "./Counter" export default function Page() { return (

Dashboard

) } ``` Where: ```jsx "use client" import { useState } from "react" export default function Counter() { const [count, setCount] = useState(0) return ( ) } ``` So: ```text Server ↓ Client ``` is a very normal composition pattern. --- # Server vs Client: A Real Example Imagine an e-commerce product page. The page needs to: - Fetch product details - Read inventory - Display description - Show reviews - Let users select quantity - Let users add products to cart A good architecture might be: ```text ProductPage SERVER │ ├── ProductInformation SERVER ├── ProductDescription SERVER ├── ProductReviews SERVER │ ├── QuantitySelector CLIENT └── AddToCartButton CLIENT ``` Server-side work: ```text Database queries Data fetching Product information SEO content ``` Client-side work: ```text Clicks State Quantity changes Cart interaction ``` That's exactly what Server and Client Components are designed to let you do. --- # What About `async/await`? Server Components can themselves be [asynchronous](/javascript/promises-asynchronous-javascript): ```jsx export default async function Page() { const users = await getUsers() return ( ) } ``` This makes server-side data fetching extremely natural. Client Components should not be written as async React components like: ```jsx "use client" export default async function Page() { // ❌ Don't make a Client Component // an async component this way. } ``` That doesn't mean JavaScript inside Client Components can never use async code. Event handlers can absolutely be asynchronous: ```jsx "use client" export default function Form() { async function handleSubmit() { await saveSomething() } return ( ) } ``` Important distinction: ```text Async Server Component ✅ ``` versus: ```text Async Client Component itself ❌ ``` while: ```text Async function inside Client Component ✅ ``` --- # Environment Variables Server Components can access private environment variables such as: ```js process.env.DATABASE_URL ``` or: ```js process.env.SECRET_API_KEY ``` without shipping those values to the browser bundle. Client Components should never depend on private server secrets. Next.js only exposes environment variables to browser code when you've intentionally configured them as public, commonly using the: ```text NEXT_PUBLIC_ ``` prefix. For example: ```env NEXT_PUBLIC_ANALYTICS_ID=abc123 ``` means: > "Yes, this value may be available to browser-side code." So never do this with an actual secret: ```env NEXT_PUBLIC_DATABASE_PASSWORD=please-dont-do-this ``` The variable literally has "PUBLIC" in the name. Next.js tried to warn you. 😭 --- # Quick Reference | Feature | Server Component | Client Component | |---|---|---| | Default in App Router | ✅ Yes | ❌ Requires `"use client"` boundary | | Async component rendering | ✅ Yes | ❌ No | | Direct database access | ✅ Yes | ❌ Don't expose database access to browser | | Private environment variables | ✅ Yes | ❌ No | | `useState` | ❌ No | ✅ Yes | | `useEffect` | ❌ No | ✅ Yes | | Event handlers | ❌ No | ✅ Yes | | `window` / `document` | ❌ No | ✅ Yes | | `localStorage` | ❌ No | ✅ Yes | | Server-side data fetching | ✅ Excellent fit | Possible through client APIs, but different pattern | | Component JS added to client bundle | ❌ No | ✅ Yes | | Interactive browser UI | ❌ No | ✅ Yes | --- # How Do You Decide? Ask one simple question: > **Does this component need browser interactivity?** If: ```text No ``` keep it as a Server Component. If it needs: ```js useState() ``` or: ```js useEffect() ``` or: ```jsx onClick={} ``` or: ```js window ``` then make that interactive part a Client Component. --- ## Example Decision Component: ```text BlogArticle ``` Needs: ```text Fetch article Render HTML ``` Use: ```text Server Component ✅ ``` Component: ```text LikeButton ``` Needs: ```text onClick useState ``` Use: ```text Client Component ✅ ``` Component: ```text ProductPage ``` Needs: ```text Database query Render product ``` Use: ```text Server Component ✅ ``` Component: ```text ImageCarousel ``` Needs: ```text Click events Current slide state Browser interaction ``` Use: ```text Client Component ✅ ``` --- # The Mental Model The easiest way to remember all of this is: ```text SERVER COMPONENT ↓ "Can this work without browser interaction?" ``` If yes, keep it on the server. Then: ```text CLIENT COMPONENT ↓ "Does the user need to interact with this?" ``` If yes, create a small Client Component. Your application might eventually look like: ```text Page SERVER │ ├── Navbar SERVER │ └── MobileMenu CLIENT │ ├── ProductList SERVER │ ├── ProductCard SERVER │ │ └── LikeButton CLIENT │ └── ProductCard SERVER │ └── LikeButton CLIENT │ └── Footer SERVER ``` Notice what we're doing? We're not making the entire application client-side just because three buttons need to be clickable. That's the key. --- # Summary The App Router uses **Server Components by default**. Server Components are ideal for: - Data fetching - Database access - Server-side logic - Private environment variables - Reducing browser JavaScript - Rendering non-interactive UI Client Components are used when you need: - State - Effects - Event handlers - Browser APIs - Interactive UI To create a Client Component, add: ```jsx "use client" ``` at the top of the file. But don't sprinkle `"use client"` everywhere like it's seasoning. 😭 The better pattern is: ```text Keep components on the server by default ↓ Move interactivity to small client components ``` Think: ```text Server = Data + Rendering + Secrets Client = State + Events + Browser ``` Once that clicks, Server and Client Components stop feeling like two competing types of React components. They're simply two environments working together. And that's how we'll keep learning on **asif.to** — not by telling you to memorize `"use client"` and move on, but by understanding *why* the server/client boundary exists and where to place it in real applications. Once you get that boundary right, modern Next.js architecture starts making a whole lot more sense. 🚀