How to Pass Props Across the Server/Client Boundary

Pass props across the server and client boundary the same way you pass any React prop, as long as the value is serializable. Fetch or build the data in the Server Component, hand it to the Client Component as a prop, and let that component own the interactive parts, such as state and event handlers.

App.tsx

// app/dashboard/page.tsx
import TagFilter from '@/app/ui/tag-filter'
 
async function getTags() {
  const res = await fetch('https://api.example.com/tags')
  return res.json() as Promise<string[]>
}
 
export default async function DashboardPage() {
  const tags = await getTags()
  return <TagFilter tags={tags} />
}

This page is a Server Component, so it runs only on the server. It fetches an array of tag strings and passes that array straight into TagFilter as a prop named tags.

App.tsx

// app/ui/tag-filter.tsx
'use client'
import { useState } from 'react'
 
export default function TagFilter({ tags }: { tags: string[] }) {
  const [selected, setSelected] = useState<string | null>(null)
  return (
    <ul>
      {tags.map((tag) => (
        <li key={tag}><button onClick={() => setSelected(tag)}>{tag}</button></li>
      ))}
    </ul>
  )
}

TagFilter runs on the client. The use client directive is there because this component needs useState and a click handler, neither of which a Server Component can use. Clicking a tag button updates the highlighted tag locally with no server round trip.

Why the prop has to be serializable

Next.js sends the props for a Client Component inside the React Server Component payload, a serialized data format the browser can parse. Anything that cannot be represented in that format never reaches the client, so React blocks it at build or render time instead of sending broken data.

The tags array in the example above is a plain array of strings, so it serializes without any extra work. If you tried to pass a function, such as an onTagClick handler defined in the Server Component, the build would fail instead. That exact failure is covered in Fixing "Functions cannot be passed directly to Client Components".

For a longer list of what counts as serializable and why, see What Props Can You Pass from Server to Client Components in Next.js. For a wider explanation of the directive itself, see The use client Directive Explained.

Streaming a Promise as a prop

A Promise is one of the few non-plain values React can serialize, and passing one lets a Client Component start rendering before the data behind it finishes loading. This is the practical variation on the pattern above, useful when a fetch is slow enough that you do not want it to block the whole page.

App.tsx

// app/blog/page.tsx
import Posts from '@/app/ui/posts'
import { Suspense } from 'react'
 
export default function Page() {
  const posts = getPosts()
  return (
    <Suspense fallback={<p>Loading posts...</p>}>
      <Posts posts={posts} />
    </Suspense>
  )
}

Page still runs on the server, but it deliberately does not await getPosts(). Skipping the await is what makes this a Promise prop instead of a resolved value, and the Suspense boundary tells Next.js what to show while that promise is still pending.

App.tsx

// app/ui/posts.tsx
'use client'
import { use } from 'react'
 
type Post = { id: string; title: string }
 
export default function Posts({ posts }: { posts: Promise<Post[]> }) {
  const allPosts = use(posts)
  return (
    <ul>
      {allPosts.map((post) => <li key={post.id}>{post.title}</li>)}
    </ul>
  )
}

Posts runs on the client and needs use client because use() only works inside a Client Component. Calling it with the posts promise suspends this component until the promise resolves, so the browser first shows the Suspense fallback, then swaps in the rendered list once the data arrives.

Common mistakes

• Awaiting the data in the Server Component before passing it down, which removes the streaming benefit and turns the Promise back into a resolved value.
• Passing a Promise prop into a component that is not wrapped in a Suspense boundary, which throws instead of showing a fallback.
• Passing a function, such as an inline click handler, from a Server Component into a Client Component, which fails because functions are not serializable.
• Passing a class instance, such as a custom model object, instead of converting it to a plain object first.
• Forgetting use client on the component that needs state, an event handler, or the use hook.