Dynamic routes and partial pre-rendering (PPR)

[valleywood]

I'm migrating a large solution from Page router to App router and was exited about the PPR functionality.
We're having a dynamic slug for our products (there are thousands of them) like this products/[slug]

The idea was to have product information (that doesn't change that often and are not user group specific etc) to be rendered server side so that it is included in the initial document file sent to the browser. Then things like price and product recommendations could be streamed with Suspense to the client dynamically.

To make the routes dynamic i added a generateStaticParams function like this in my products/[slug]/page.tsx file

export async function generateStaticParams() {
  return [];
}

This works fine as long as i wrap both my components inside a Suspense like this:

"use cache";
...
<Suspense>
        <ProductData params={params} />
</Suspense>
<Suspense>
        <RelatedProducts params={params} />
</Suspense>
...

This however makes both ProductData and RelatedProducts being streamed to the client leading to a worse user experience and decreased LCP values etc.

What I would like is this:

"use cache";
...
<ProductData params={params} />
<Suspense>
        <RelatedProducts params={params} />
</Suspense>
...

This would actually make the ProductData appear in the initial document and RelatedProducts being streamed just as i wanted.
However this setup causes console errors in the browser:

Server  Error: Route "/products/[slug]": A component accessed data, headers, params, searchParams, or a short-lived cache without a Suspense boundary nor a "use cache" above it. See more info: https://nextjs.org/docs/messages/next-prerender-missing-suspense
    at ProductPage [Server] (<anonymous>:1:29)
    at resolveErrorDev (react-server-dom-webpack-client.browser.development.js:2856:1)
    at getOutlinedModel (react-server-dom-webpack-client.browser.development.js:2215:1)
    at parseModelString (react-server-dom-webpack-client.browser.development.js:2411:1)
    at Object.eval (react-server-dom-webpack-client.browser.development.js:4085:1)
    at JSON.parse (<anonymous>)
    at initializeModelChunk (react-server-dom-webpack-client.browser.development.js:1720:1)
    at getOutlinedModel (react-server-dom-webpack-client.browser.development.js:2150:1)
    at parseModelString (react-server-dom-webpack-client.browser.development.js:2507:1)
    at Array.eval (react-server-dom-webpack-client.browser.development.js:4085:1)
    at JSON.parse (<anonymous>)
    at initializeModelChunk (react-server-dom-webpack-client.browser.development.js:1720:1)
    at resolveConsoleEntry (react-server-dom-webpack-client.browser.development.js:3146:1)
    at processFullStringRow (react-server-dom-webpack-client.browser.development.js:3936:1)
    at processFullBinaryRow (react-server-dom-webpack-client.browser.development.js:3837:1)
    at processBinaryChunk (react-server-dom-webpack-client.browser.development.js:4058:1)
    at progress (react-server-dom-webpack-client.browser.development.js:4326:1)

I've tried with the code below and then it works as expected with no console error and the product information being rendered in the initial document but that isn't a feasible solution having thousands of products that is updated/added/deleted continuously

export async function generateStaticParams() {
  // Return ALL possible slugs at build time
  return KNOWN_PRODUCTS.map(slug => ({ slug }));
}

Is this a known limitation of PPR and should I go for a ISR + client setup instead or does anyone know of a way to have dynamic routes (with slugs) working with PPR?

[samselikoff]

Sorry you ran into this – we're currently working on improving these errors + documenting all the use cases for the upcoming stable release, but it's all admittedly a bit confusing right now!

My first question is about your desired behavior. You wrote

The idea was to have product information (that doesn't change that often and are not user group specific etc) to be rendered server side so that it is included in the initial document file sent to the browser. Then things like price and product recommendations could be streamed with Suspense to the client dynamically.

When you say rendered server-side, do you mean prerendered? Like during build time?

Based on the rest of your comment, I gather that you don't want to prerender the pages, since there are many dynamic slugs. In that case, do you just mean that you want to server-render the pages at request time?

[valleywood]

@samselikoff Thanks for reaching out and sorry I was being a bit sloppy here in my description about "server-side"

The desired behavior was actually having ISR with on-demand build at runtime (thinking that having dynamic slug with thousands of product pages pre-rendered at build time wasn't the best choice probably. Products can be added, removed or updated randomly anyways)

So I'd like the users to get a cached markup served in the document file (for user two and onwards) which is the traditional ISR pattern.

Then I thought i could add Suspense to this get "holes" to fill in more dynamically with SSR rendered streamed components. Say that this could for example be a PersonalizedRecommendations component that's not suitable for caching in the same way (the cache would blow up with all potential combinations).

What I've come to realize is that having ISR with "holes" like this with Suspense doesn't bypass the cache, so the Suspense wrapping in this case is basically useless. Options that remains are:

• Make PersonalizedRecommendations a client component and fetch on the client with cache: 'no-store'.
• Make the whole page dynamic = 'force-dynamic' (loses ISR).
• Adopt experimental “use cache”/PPR <= This was what i aimed for

I actually got around the first error display in the original post by just dropping the generateStaticParams function completely but it seems like the solution with use cache is much more sensitive to use with for example getRequestConfig from 'next-intl/server' for example (accesses request headers)

That worked just fine for the ISR case. Tried in all possible ways to work with next-intl and getting things working with "use cache" but it always ended up with having to revert to ISR instead:

export const revalidate = 600;
export const dynamic = 'force-static';
export const fetchCache = 'force-cache';
export const dynamicParams = true;

Reading some more about this issue here:
amannn/next-intl#1493