รูปแบบการประกอบคอมโพเนนต์ฝั่งเซิร์ฟเวอร์และฝั่งไคลเอนต์

You often need interactivity (Client) wrapping data-heavy UI (Server). The trick is composing them so Server Components are not pulled into the client bundle.

A Client Component cannot import a Server Component, because importing would force it to run on the client. But it can render one passed as children.

Render a Server Component inside a Client Component by passing it through props from a parent Server Component.

The Client Component receives the already-rendered Server output as children and never needs to know how it was built.

The Server Component renders on the server; only its output (serialized RSC payload) reaches the client. The Client Component just slots it in — no server code shipped.

Props passed from Server to Client Components must be serializable. You cannot pass functions, class instances, or Dates without care — but you can pass plain data and JSX children.

Keep "use client" as deep in the tree as possible. A small leaf Client Component keeps most of the tree server-rendered and the bundle small.

Client context providers wrap Server children fine: define the provider as a Client Component and pass server-rendered children through it.

Importing a library that uses browser APIs into a Server Component breaks it. Isolate such code behind a Client Component boundary.

You can deeply interleave: Server layout, Client sidebar toggler, Server content, Client like-button — each boundary minimal and intentional.

Think of Client Components as holes in a server-rendered tree. Data flows down as props/children; interactivity lives only where needed.

You learned the key composition pattern: Client Components cannot import Server Components but can render them as children. Keep client boundaries small and deep, pass serializable props, and treat Client Components as interactive holes in a server-rendered tree.