[Feedback] Support/Docs for Next.js v16 "Cache Components"

[GRA0007]

We have a Next.js site that currently is mostly statically rendered at build-time, and with an already fairly complex routing structure and proxy file, we're not interested in introducing more complexity via the precompute method this library provides.

Now that Next.js v16 is out and supports cache components (previously known as partial pre-rendering or PPR), it would be nice to have support for this alternate method of fetching flags in a static route.

We're considering loading flags on the client side at this time, as we can't see any functional difference to the end-user if an element pops into view via the server or a client fetch, aside from the fact that the server now has extra work to do, more costs for us etc. However this library, at least the Next.js adaptor, does not support the client side at all by default, which feels like a significant omission, especially before cache components were promoted to stable.

[dferber90]

Great questions. There are a few things here.

Your pages are currently mostly statically rendered at build-time. This means you can serve them from the CDN, globally. A user in any geographic location is served near to them. This is the fastest and cheapest possible experience.

If you use precompute then you keep the benefit of static pages from the CDN, while adding slight overhead by running proxy.ts in front of the CDN to decide which version of the page to serve. This is the fastest possible experience when using flags. This should only be used if your flag values are shared by many users. So not when flag values are user specific as you would never get cache hits in the CDN due to high cardinality.

If you were to move to cache components then users would be served from your Vercel Function region(s), which is geographically further away from your users than the CDN nodes.

If you were to use flags client-side you would also be able to serve from the CDN and would not need proxy. But, and this is a really big one, you would either have to show a loading state/skeleton until the flag value is resolved, or you would need to risk showing the potentially wrong version optimistically and causing jank and layout shift once the flag value settles. And this also causes a waterfall since you're not passing the value down to the client. Instead you send the whole page and then go back to a server to evaluate flags.

That's why we always recommend evaluating flags server-side, either through precompute or otherwise.

It's fair that the current API is not ideal for precompute or using flags client-side in a sane way. We are working on more ergonomic solutions and have found a very promising approach. Hope we can share more about it soon.

[GRA0007]

Oh great, thanks for the detailed message. Yeah I agree in most cases flags should be used on the server side, especially if a flag decides something in a parent component that then needs to fetch different data to render it's children etc.

For simple things though such as showing a button if a flag is set, it would be very convenient to check that flag from the client side, particularly if that button is below the fold, as it's not critical for it to resolve immediately.

Looking forward to seeing future updates :)