# Stop Defaulting to "use client": A Practical Mental Model for React Server Component Architecture

DevFeed: [Stop Defaulting to "use client": A Practical Mental Model for React Server Component Architecture](<https://devfeed.tech/articles/stop-defaulting-to-use-client-a-practical-mental-model-for-react-server-component-architecture-20101.md>)

Original publisher: [Read original article](<https://medium.com/jobteaser-dev-team/stop-defaulting-to-use-client-a-practical-mental-model-for-react-server-component-architecture-d94dd0a73364?source=rss----bd77d16a0035---4>)

Author: Clarisse Leduc

Published: 2026-04-21T11:14:11Z

Content type: tutorial

Language: en

Sources: [JobTeaser](<https://devfeed.tech/sources/jobteaser.md>)

Topics: [React](<https://devfeed.tech/topics/react.md>), [Next.js](<https://devfeed.tech/topics/next-js.md>), [Web Development](<https://devfeed.tech/topics/web-development.md>)

Tags: [architecture](<https://devfeed.tech/tags/architecture.md>), [front-end-development](<https://devfeed.tech/tags/front-end-development.md>), [how-to](<https://devfeed.tech/tags/how-to.md>), [next-js](<https://devfeed.tech/tags/next-js.md>), [nextjs](<https://devfeed.tech/tags/nextjs.md>), [react](<https://devfeed.tech/tags/react.md>), [react-server-component](<https://devfeed.tech/tags/react-server-component.md>), [software-engineering](<https://devfeed.tech/tags/software-engineering.md>)

## AI overview

A practical guide to React Server Component architecture in Next.js. It recommends defaulting to Server Components and using Client Components only where interactivity is required, keeping client boundaries close to interactive elements to reduce shipped JavaScript.

## Source excerpt

How thinking in server-first component boundaries can simplify data flow and reduce client JavaScript in Next.js applications. When I first started working with the Next.js App Router, I kept running into the same situation. Components would suddenly break -- usually after adding a hook or a click handler. The fix felt obvious: add "use client". But after doing this a few times, I realised something: I was slowly turning my application back into a traditional client-side React app. Which defeats the whole point of React Server Components. The real challenge isn't learning how to use Client and Server Components. It's learning how to decide where code should run. Once that mental model clicked, structuring Next.js applications became much clearer -- and often more performant. The Mental Model React Server Components introduce a simple but powerful separation of responsibilities. A helpful rule of thumb: Default to Server Components. Use Client Components only when interactivity is required. Think of it like this: This small shift in thinking has a big impact on how you design component trees. A Simple Example Consider a typical product page. export default async function ProductPage({ params }) { const product = await getProduct(params.id, { cache: "no-store" }) if (!product) { notFound() // Next.js helper for 404 pages } return ( <> <ProductDetails product={product} /> <AddToCartButton productId={product.id} /> </> ) } Here: ProductPage -> Server Component ProductDetails -> Server Component AddToCartButton -> Client Component Only the interactive part runs in the browser. Everything else stays on the server, meaning less JavaScript shipped to the user. The "use client" Boundary One subtle detail that often surprises developers is that "use client" creates a boundary in the component tree. If a component is marked as a Client Component, all of its children become Client Components too. Example: "use client" export default function Page() { return ( <Layout> <ProductInfo /