Chapter 8 quiz may be misleading about static rendering

[eric-burel]

Hi,

The chapter 8 quiz will ask "What kind of information can only be known at request time?", including "URL path" and "cookies and URL search params" as possible answers, cookies/searchParams being the expected response.

The sentence above also states "Request Time Information - Dynamic rendering allows you to access information that can only be known at request time, such as cookies or the URL search parameters."

However, I find it misleading:

• the URL is part of the HTTP request: you don't know it at build-time. What you do at build-time is that you precompute a set of URL, that may or may not be visited by actual users. You know the final URL only at request-time.
• the same reasoning can perfectly apply to cookies and search params : you could prerender pages based on cookies and search params, and then pick the right page based on the actual value you see in the HTTP request. So cookies and search params are not known at request-time, but they could perfectly be prerendered.

The difference between URL, cookies and searchparams lies in their cardinality. Cookies and searchparams are harder to cache because they can take many values. So it's simply a design choice not to support them, it could be confusing for end users. Not supporting cookies or searchparams is not a limitation of static rendering as a concept.

Another difference is the need for derived values: cookies are often used to then trigger databases calls, in order to get the current user. But this apply only to some cookies, you can also have more trivial cookies like the current light or dark theme, you could perfectly statically render that.

I've studied this topic extensively over the past years (with some math), because this idea that static rendering is limited to URL is sticking around in many frameworks and learning resources. You can currently bypass this limitation by involving edge middleware and it's becoming a common pattern.

For instance, @vercel/flags precomputed flags pattern uses this approach, and I've described a similar pattern earlier at Smashing Magazine et React Advanced London.

To sum it up, I'd suggest rephrasing this quiz, introducing this notion of cardinality:
"High cardinality values: Dynamic rendering allows you to access information that are difficult to render at build-time because they can take many value, such as URL search parameters or users authentication tokens in cookies"

And in the quiz maybe rephrase to "What kind of information are usually retrieved at request time?", with the idea that it's an usual way of doing static/dynamic rendering but not a conceptual limitation.

[alfonsusac]

I think the question asks in the context of what is possible within Next.js. Implying that "these are the stuff that is only known at request time in Next.js" which the answer would of course be "Cookie and URL SearchParams. This is after all, learn Next.js as a framework not learn Web Development which of course, you were right in saying that both of Cookie and URL SearchParams can be statically rendered.

the URL is part of the HTTP request: you don't know it at build-time. What you do at build-time is that you precompute a set of URL, that may or may not be visited by actual users. You know the final URL only at request-time.

We don't know the URL at build-time but we can "capture" known set of URL to statically render something. This would imply that some of the URL are known (but not all) at build time.

It is still important to balance out to let learners know what is teorhetically possible and still focusing down on the concepts that are only possible practically in the current version of the Next.js framework.