Documentation needs to clarify how to handle blocking patterns in Cache Components.
The issue highlights a need for clearer documentation on how to intentionally block in Cache Components, particularly for scenarios like determining login state without using Suspense boundaries. The requirements are somewhat clear but involve understanding Cache Components deeply. The main blocker is ensuring the documentation accurately reflects the intended usage patterns.
We've all seen this error:
Runtime data such as
cookies(),headers(),params, orsearchParamswas accessed outside of<Suspense>.
First, I want to say that I really like that Cache Components forces to find where you block unnecessarily. Given the reputation of App Router as being somehow slow, I think forcing to add Suspense boundaries does help in the sense that developers can see that it's their code is blocking, and have an opportunity to fix it.
However, this seems to make some common patterns impossible to express without warnings.
In particular, I'm interested in the pattern where the app's UI depends on whether you're logged in or not. A logged-in and logged-out states are significantly different in their nature so a <Suspense> boundary is not always adequate or appropriate, and it could not be determined before reading cookies() either.
Consider this UI from a website I use:
https://github.com/user-attachments/assets/560ab953-724e-4fab-abd4-78e2c320a5cc
(They're using Next but I don't think they're using CC; I'm just using this example because it's illustrative)
Notice a placeholder in the piece of UI corresponding to the user avi. I personally hate when websites do that.
This kind of UX feels like a relic of the jamstack era when the client actually was unable to determine whether you're logged in or not and so it had to display a placeholder while figuring out. Many people who use Next don't actually want to do jamstack and are fine with running some code dynamically.
The problem is that this "jamstacky" UX pattern seems forced upon the developers by the Cache Components approach, even when there's no actual perf upside for the user. Reading cookies() and then deciding to display the avi (or not) does not necessarily need any expensive data roundtrip justifying sending a shell without it. In my opinion, for the kind of apps I built, the top bar (including the avi) should just
Claim this issue to let others know you're working on it. You'll earn 10 points when you complete it!