Reading cookies in Client Components during server-rendering with React's use() hook (Next.js 15)

[anicioalexandre]

Summary

Context
With Next.js 15, cookies() is now async. I need to read cookies in Client Components during their server-side rendering phase. I've implemented this pattern using React's use() hook:

// useCookie.ts
"use client"
import { use } from 'react'

export function useCookie(name: string) {
  if (typeof window === 'undefined') {
    const cookies: () => Promise<ReadonlyRequestCookies> = require('next/headers').cookies 
    const cookieStore = use(cookies())
    return cookieStore.get(name)?.value
  }
  return getCookieClient(name) // getting a cookie using client side tools, like js-cookie
}

// ClientComponent.tsx
"use client"
import { useCookie } from "./useCookie"

const ClientComponent = () => {
  const cookie = useCookie("myCookie")
  
  return (
    <div>
      <h1>This is a Client Component</h1>
      <p>Getting a Cookie: {cookie}</p>
    </div>
  )
}

export default ClientComponent

Then we would just render this component in a server component page.

• Is using use() to handle async cookies in Client Components during SSR considered an anti-pattern?
• Is it ok to have such a hybrid function to get cookies during server and client renders of a component?
• Would you recommend a different way to achieve this?

My goal is to have a better UX during reloads and phase rendering transitions. For example, I have a cookie that saves the state of the sidebar menu (collapsed or expanded). During a reload, I want to ensure that it remains in the last state during both server and client renders of a client component.

Additional information

No response

Example

No response

[baljir0901]

Hey! 👋 Really interesting question — I explored this too.

❗ TL;DR: Using use(cookies()) inside a "use client" component is not recommended

While it technically works during the server-rendering phase of a Client Component, it risks:

• ⚠️ Breaking hydration or causing mismatch warnings
• ⚠️ Becoming unsupported in future React versions
• ⚠️ Mixing server logic into client space, which goes against React’s model

---

✅ Recommended Pattern

Instead, read cookies in a Server Component and pass them to the Client Component as props:

// page.tsx (or layout.tsx)
import { cookies } from "next/headers";
import ClientComponent from "./ClientComponent";

export default function Page() {
  const sidebarState = cookies().get("myCookie")?.value ?? "expanded";
  return <ClientComponent initialSidebar={sidebarState} />;
}

[anicioalexandre]

Hey @baljir0901, thanks for replying. Regarding the points you mentioned:

⚠️ Breaking hydration or causing mismatch warnings

I am doing this function to exactly avoid these mismatches, if the client component is not able to get the cookie during the server render, the UI risks to be mismatched

⚠️ Becoming unsupported in future React versions

You mean use being deprecated or something? Because it doesn't seem likely, they actually incentivize its use over useContext for example:

use is preferred over useContext because it is more flexible.

⚠️ Mixing server logic into client space, which goes against React’s model

Right, I'm not so sure if I got it, because server and client components are close together, since client components should be rendered during SSR by default

[anicioalexandre]

@icyJoseph could you advise please?

[renatorib]

I'm doing the same here... didn't had any problem yet.

Just a side note: React.use isn't a hook, it means it don't follow the hooks rules (for conditional ones, looping, respecting call order, etc.), as you already should know by using it inside an if.

But when you name your isomorphic function as useCookie you're putting it in the hooks rules jail (at lest of linters) false positively.

Just name it getCookie, it's fine and you'll be free from those annoying rules. The only concern is that it still will be restricted to components and hooks as you cannot use React.use outside of the react tree.

[biyash-1]

Hey! I’ve been experimenting with this too — here’s my take:
Using use() inside a client component to read async cookies technically works, but it’s not really the intended way React/Next wants us to handle things. use() is mainly meant for server components, so using it in client components could cause unexpected issues in the future.
The safer way is to read the cookie in a server component and then pass it as a prop to your client component. That way, your client component always has the correct initial value during SSR, so things like your sidebar state won’t flicker when the page reloads.
example:
// Page.tsx (Server Component)
import { cookies } from "next/headers"
import ClientComponent from "./ClientComponent"

export default async function Page() {
const cookieStore = await cookies()
const myCookie = cookieStore.get("sidebarState")?.value
return
}

`// ClientComponent.tsx (Client Component)
"use client"

export default function ClientComponent({ initialState }) {
  return (
    <div>
      <h1>Sidebar State: {initialState}</h1>
    </div>
  )`
}If you want the client to update the cookie when the user interacts (like toggling the sidebar), that’s fine too — just update both the cookie and the React state.

[icyJoseph]

use() is mainly meant for server components, so using it in client components could cause unexpected issues in the future

use is a React client hook. There's valid patterns with use that allow you to render more UI while streaming the use'd value into a client component.

And yes, "derived data" from the cookie (which in some cases might the cookie itself, though I'd be careful with doing that)

There's an upcoming API, https://react.dev/reference/react/experimental_taintUniqueValue#noun-labs-1201738-(2), which you can use to prevent certain data from passing through to the client.

[renatorib]

use() is mainly meant for server components

No, it's not. Futhermore, React docs for use() explicitly says:

When fetching data in a Server Component, prefer async and await over use.