Is there a general solution to avoid blocking using cookies with CachedComponents and SSR?

[victorpavlenko]

Everything works individually.
SSR works.
PPR works.
Cookies work.
But when you need to do all of this together for authorization, the first thing the user sees is Loading...

Smart people, I know you exist. Can you help me come up with a solution to get around this?

import { Suspense } from "react"
import { HydrationBoundary, dehydrate } from "@tanstack/react-query"
import { getQueryClient } from "@/lib/queryClient"
import { ApiResponse, Self } from "@/types"
import { cookies } from "next/headers"
import Component from "@/entrypoints/main/home"
import LayoutWrapper from "@/entrypoints/main/layout"

async function HomePageContent() {
    const queryClient = getQueryClient()
    const cookieStore = await cookies()
    const token = cookieStore.get("accessToken")?.value

    await queryClient.prefetchQuery({
        queryKey: ["user"],
        queryFn: async () => {
            const response = await fetch(`${process.env.NEXT_PUBLIC_API_ENDPOINT}auth/self`, {
                headers: {
                    Authorization: `Bearer ${token}`
                }
            })
            const json: ApiResponse<Self> = await response.json()
            return json.data
        },
        staleTime: 5 * 60 * 1000,
    })

    return (
        <HydrationBoundary state={dehydrate(queryClient)}>
            <LayoutWrapper>
                <Component />
            </LayoutWrapper>
        </HydrationBoundary>
    )
}

export default function HomePage() {
    return (
        <Suspense fallback={<div>Loading...</div>}>
            <HomePageContent />
        </Suspense>
    )
}

[Arjun-M]

Hi @victorpavlenko! 👋

I feel your pain. This is the classic "Dynamic Hole" vs. "App Shell" conflict in the Next.js App Router.

The issue isn't that the technologies don't work together; it's strictly about where you are forcing the browser to wait.

The Problem: You are "Blocking" the Shell 🛑

In your code, you are calculating the "Dynamic" part (Cookies + API Fetch) before you render the LayoutWrapper.

// ❌ Your current flow:
// 1. Wait for Cookies (Async)
// 2. Wait for API Fetch (Async)
// 3. START Rendering <LayoutWrapper> (Header, Sidebar, etc.)
// Result: User sees "Loading..." (the Suspense fallback) for EVERYTHING.

Because HomePageContent is async and wraps your Layout, the Layout cannot exist until the data exists.

The Solution: Lift the Shell (Granular Suspense) 🧠

To fix this, you need to move the static parts (the Layout) outside of the async boundary, and only wrap the user-dependent parts in Suspense.

This allows Next.js (and PPR) to send the LayoutWrapper immediately (Status 200, immediate paint), and then stream in the user content where the "Loading..." text is.

Step-by-step Refactor:

1. Create a dedicated component for the User Data:
Move the fetch logic into a smaller component that only renders the part that needs the data.

// components/UserFeed.tsx (or similar)
import { HydrationBoundary, dehydrate } from "@tanstack/react-query"
import { getQueryClient } from "@/lib/queryClient"
import { cookies } from "next/headers"
import Component from "@/entrypoints/main/home" // Renaming 'Component' to something specific is good practice!

export default async function UserFeed() {
    const queryClient = getQueryClient()
    const cookieStore = await cookies() // This makes THIS component dynamic
    const token = cookieStore.get("accessToken")?.value

    await queryClient.prefetchQuery({
        queryKey: ["user"],
        queryFn: async () => {
            const response = await fetch(`${process.env.NEXT_PUBLIC_API_ENDPOINT}auth/self`, {
                headers: { Authorization: `Bearer ${token}` }
            })
            return (await response.json()).data
        },
    })

    return (
        <HydrationBoundary state={dehydrate(queryClient)}>
            <Component />
        </HydrationBoundary>
    )
}

2. Update your Page to render the Layout FIRST:
Now, HomePage renders the Layout immediately. The Suspense boundary only blocks the UserFeed.

// app/page.tsx
import { Suspense } from "react"
import LayoutWrapper from "@/entrypoints/main/layout"
import UserFeed from "@/components/UserFeed"
import { Skeleton } from "@/components/ui/skeleton" // Much better than "Loading..." text!

export default function HomePage() {
    return (
        /* ✅ Layout renders INSTANTLY because it is not awaited */
        <LayoutWrapper>
            <Suspense fallback={<Skeleton className="h-96 w-full" />}>
                <UserFeed />
            </Suspense>
        </LayoutWrapper>
    )
}

"But what if my Layout needs the user data?" (e.g., Avatar in Header)

If your LayoutWrapper needs the user info (like for the top-right avatar), do not pass the data down from the Page. instead, put a second independent Suspense boundary inside the Layout itself.

// Inside LayoutWrapper.tsx
<nav>
   <Logo />
   <Suspense fallback={<AvatarSkeleton />}>
      <UserAvatar /> {/* Fetches its own data independently */}
   </Suspense>
</nav>

This pattern—streaming parallel data requirements—is how you unlock the true power of the App Router and avoid that "all-or-nothing" loading state! 🚀

Have a look at this video to understand better

Let me know if that fixes it! (If it does, purely optional, but marking this as the answer helps others find the solution too!)"

[victorpavlenko]

@Arjun-M Thanks for this answer!

But as you understand, our apps has a deep tree, and before reaching the <UserFeed />, it passes through 10 other components.

(And also we are not just talking about the Header, there are a couple dozen of these components, Footer etc, with their own requests, and tree. For simplicity, we will only discuss the Header)

And the dilemma is:

1. whether to wrap the entire <Header /> in <Suspense >, which makes no sense in this case.

2. or should create 10 more wrappers, to extract the client logic and hooks like (useEffect, usePathname, etc.) so that by the time it reaches a depth of 10 components, it doesn't get broken by client components.

And how is this illogical? A lot of work for no apparent reason.

I'm really interested in figuring out what I can use this for, maybe I don't understand it, but at the moment it just seems useless to me...

[icyJoseph]

It feels like there's a piece missing here (or maybe it's just been a long day). Like a way to tell react-query read this data from already started work.

 const onGoingWork = cookies().then((store) => {
       return fetchSomeData(store)
 })

If we were able to pass that promise to react-query, and associate it with a key, then we'd be set. Today, in the server, what we can do is say, react-query, here's a function to kick off that work, and that doesn't go along w/ some Cache Components runtime behavior tracking.

  queryClient.prefetchQuery({
    queryKey: ['some-data'],
    queryFn: fetchSomeData, // here if we could say, I've already started this work for you...
  })

One workaround is to pass the onGoingWork to a client, and do React.use(onGoingWork) and then pass that to react-query via queryClient.setQueryData() (or pass the promise, and .use on the query side?)

• https://react.dev/reference/react/use#streaming-data-from-server-to-client

There's likely some consideration to be made for waterfalls, and what to do upon mutations too, and what kind of queryFn, should the client use, so not saying this is a simple lift either.