How do cache components work with highly dynamic pages?

[tobiaspickel]

Hi there,
I recently played around with cache components and I do find it very confusing.
I walked through the docs multiple times tried to get a good mental model of how it works but somehow it did not click yet.
What confuses me the most is that I tried to just use some of the examples from the docs and they do not work for me.
I do not understand what I am doing wrong and what am I missing.

It is stated multiple times that now with cacheComponents all pages are dynamic by default.
That is nice and actually what I expected, but I see some really strange things in use cases that should be easy and straight forward.

For example:
I copied this basic example here straight from the docs.
But it does not work.
I do get the Runtime data was accessed outside of <Suspense> error.
I do have a test repo running the latest canary here.
The error goes away if I do add

export const generateStaticParams = () => {
  return [{ id: "0" }]
}

at the top of the file.
I do not understand why this is necessary and if this is the proper way to do it as I didn't find any docs on this.

In the current state I do not feel very confident adapting cacheComponents as it is very hard to grasp what is going on.
Feels almost like going from regular SSR to Client/Server Components all over gain.
In theory it should be straight forward but in practices there are either still many rough edges or I simply do not under stand it.

Wrapping all of my content in Suspense just seems like a bad idea and rework all components to move dynamic apis down is just not feasible in a large scale project.

I would love to have a very simple api to have something like ISR but on component level.
I thought cache components is exactly that but I do not get how to use it right 😓.
Please help I am desperate and confused 😆.

[icyJoseph]

Hiyo, I am about to merge an update that fixes that example.

generateStaticParams makes it so that the param on that page is known at build time, so you can read it without Suspense around it, and prerender can go ahead and generate that page.

Then, at runtime, the first time a new dynamic params is requested, it render blocks, serves and saves to disk. The next time this param is requested it serves immediately.

Without at least one sample parameter, (docs for this coming up too) - then there's no way to check what this route does.

IIRC, we are trying to differentiate this, and other errors, so that you'd end up in a more appropriate error page. For example: https://nextjs.org/docs/messages/empty-generate-static-params would've been arguably more helpful.

[iltimasd]

Hi @icyJoseph!

I know docs are otw, but was hoping you could provide some color here, currently working on a implementation where I need to decide to wrap or not wrap a component in Suspense when using param. Caught one line in the docs (only ref to this I could find) referring to providing one sample to generateStaticParams and now my dynamic content is caching as I hoped.

I am about to merge an update that fixes that example

To confirm, this is just updating docs, not a change in API that's upcoming?

Without at least one sample parameter, (docs for this coming up too) - then there's no way to check what this route does.

Could you provide a little detail here, trying to understand the Next "magic" here; why does providing an arbitrary param allow caching w/o Suspense? Is it important that provided sample hit all the control flow in the component to cache (psuedo-ish below)? or is this just idiosyncratic behavior of Cache Components?

async function CachedContent({ path }: { path: string[] }) {
  'use cache: remote';
  if(Number(path)>50){
   let data = fetchOneWay();
   <RenderOneWay {data}/>
  } else {
   let data = fetchAnotherWay();
   <RenderAnotherWay {data}/>
}

[icyJoseph]

Yes docs only for now. I've frame it as build-time validation, but I am already thinking of reframing it into more of a way, in which Next.js gives you feedback to help you see where dynamic behavior exists.

It is not so much magic really, but how would one figure out the static shell, other than running the code. You provide a param, so Next.js can make more progress in your route, so more of the page can be added to the prerendered HTML. I think there's also a compounded benefit when you have 2-3 params, but I haven't worked with it beyond the demo state.

In short, the more params variations you can provide the pages you can prerender fully to have a static shell and the higher your confidence is that your pages are correct. When you have multiple segments, even partial static shells can be made.

Sorry if a bit short answer, it's been a long week 😅