Skip to main content
GoodFirstPicks
DashboardIssuesReposLeaderboard

GoodFirstPicks by Leaveitblank © 2026

CreatorRequest a RepoPrivacy PolicyTerms of Service
Docs: How to intentionally block in Cache Components? | GoodFirstPicks

Docs: How to intentionally block in Cache Components?

vercel/next.js 24 comments 1mo ago
View on GitHub
mediumopenScope: somewhat clearSkill match: maybeNext.jsTypeScriptReact

Why this is a good first issue

Documentation needs to clarify how to handle blocking patterns in Cache Components.

AI Summary

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.

Issue Description

What is the documentation issue?

We've all seen this error:

Runtime data such as cookies(), headers(), params, or searchParams was 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

GitHub Labels

linear: nextCache ComponentsDepth

Want to work on this?

Claim this issue to let others know you're working on it. You'll earn 10 points when you complete it!

Risk Flags

  • requires understanding of Cache Components
  • potential UX implications
Loading labels...

Details

Points10 pts
Difficultymedium
Scopesomewhat clear
Skill Matchmaybe
Test Focusedno
AssigneeicyJoseph