Cache Components with Page params errors with uncached data message

[nemwark]

Sorry to bring up a close issue. I just hit the same problem when I try to adopt cacheComponent.

What is the recommended way to handle this situation with await params

The renders are not always depend on params or searchParams.
For eg, if the searchParams is only just a ?redirect=url, in this case, the render is totally independent of the searchParmas

The Mixed caching strategies(code cited below) given by the Doc is not working.

import { Suspense } from 'react'
import { connection } from 'next/server'
import { cookies } from 'next/headers'
import { cacheLife, cacheTag } from 'next/cache'
 
// Static product data - prerendered at build time
async function getProduct(id: string) {
  'use cache'
  cacheTag(`product-${id}`)
 
  // This is cached at build time and shared across all users
  return db.products.find({ where: { id } })
}
 
// Shared pricing data - cached at runtime in remote handler
async function getProductPrice(id: string) {
  'use cache: remote'
  cacheTag(`product-price-${id}`)
  cacheLife({ expire: 300 }) // 5 minutes
 
  // This is cached at runtime and shared across all users
  return db.products.getPrice({ where: { id } })
}
 
// User-specific recommendations - private cache per user
async function getRecommendations(productId: string) {
  'use cache: private'
  cacheLife({ expire: 60 }) // 1 minute
 
  const sessionId = (await cookies()).get('session-id')?.value
 
  // This is cached per-user and never shared
  return db.recommendations.findMany({
    where: { productId, sessionId },
  })
}
 
export default async function ProductPage({ params }) {
  const { id } = await params
 
  // Static product data
  const product = await getProduct(id)
 
  return (
    <div>
      <ProductDetails product={product} />
 
      {/* Dynamic shared price */}
      <Suspense fallback={<PriceSkeleton />}>
        <ProductPriceComponent productId={id} />
      </Suspense>
 
      {/* Dynamic personalized recommendations */}
      <Suspense fallback={<RecommendationsSkeleton />}>
        <ProductRecommendations productId={id} />
      </Suspense>
    </div>
  )
}
 
function ProductDetails({ product }) {
  return (
    <div>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
    </div>
  )
}
 
async function ProductPriceComponent({ productId }) {
  // Defer to request time
  await connection()
 
  const price = await getProductPrice(productId)
  return <div>Price: ${price}</div>
}
 
async function ProductRecommendations({ productId }) {
  const recommendations = await getRecommendations(productId)
  return <RecommendationsList items={recommendations} />
}
 
function PriceSkeleton() {
  return <div>Loading price...</div>
}
 
function RecommendationsSkeleton() {
  return <div>Loading recommendations...</div>
}
 
function RecommendationsList({ items }) {
  return (
    <ul>
      {items.map((item) => (
        <li key={item.id}>{item.name}</li>
      ))}
    </ul>
  )
}

Don't get fooled @daanvosdewael. Wrapping everything in Suspense or adding a loading.tsx is exactly what you DON'T want to do. That defeats the entire purpose of PPR.

Your post is completely justified, and let me explain why this is a critical issue that breaks a fundamental performance optimization pattern.

We run a site with 2M+ monthly users where performance isn't optional. It's how we dominate the competition and keep server-load low. The pattern we use, shown in the docs example you mentioned in your post, is exactly how we achieve this.

We tried cacheComponents and were, just like you, completely confused. Now with cacheComponents, accessing params throws this error, forcing us to either:

1. Wrap everything in Suspense (destroying the static shell that PPR is designed to create)
2. Completely opt out of cache components and switch back to version 15 canary to use experimental_ppr (which still works perfectly and as intended!)

The whole point of PPR is to serve a static shell instantly while streaming dynamic parts. If you wrap your entire page in Suspense, you've just made everything dynamic. You're back to square one with no static shell, no instant paint, and SEO takes a hit.

This destroys the ability to statically render external fetched data while keeping dynamic elements separate, which is the exact use case your documentation promotes.

This isn't a minor DX inconvenience. This is a performance regression that impacts real production applications at scale.

Bottom line: we're now forced to opt out of cacheComponents entirely because this error makes absolutely no sense. Accessing params shouldn't hinder us from fetching an external post and using that data to render the externally fetched part statically. That's the whole point.

Either the error is wrong, or the docs need an immediate update explaining why this formerly recommended pattern is no longer viable. This issue should definitely be reopened as it is still occurs in the latest 16.0.2 canary build. @icyJoseph

Originally posted by @xyba1337 in #85807

[icyJoseph]

That example is missing the generateStaticParams function. Otherwise, you have to unwrap the params promise within a Suspense boundary, you don't have to do it at the very top of your page neither.

I was sure I had added one there though, maybe I added it to another snippet.

The bottom thing is that params are either known at build-time through generateStaticParams, or are purely runtime data. To assert a page doesn't access uncached data, and/or has no fallbacks for blocking behavior etc.

Maybe this draft helps in the mean time: https://github.com/vercel/next.js/pull/91588/changes#diff-c94413ebcb25899d02fdb31bcd7365607bffefcfe325538c511204f38aa88784