Consider renaming "Server Context" in this repo + blog post

[karlhorky]

Hi @eric-burel, thanks so much for your Leveraging Server Context for Advanced Next.js Optimization Patterns blog post and this accompanying repo, really cool! 🙌

I was thinking that you may want to consider renaming all occurrences of "Server Context" across this repo and also in your blog post, because ServerContext appears to be something different, where you should not store very much information:

• https://twitter.com/sebmarkbage/status/1587615489605369861

I haven't seen the information stored in cache() and fetch() and similar be referred to as "Server Cache". The closest thing that I've seen is officially called "Next.js Cache", referred to here:

• Next.js 13.2 announcement blog post https://nextjs.org/blog/next-13-2#nextjs-cache
• Vercel Cache API blog post https://vercel.com/blog/vercel-cache-api-nextjs-cache

cc @sebmarkbage @timneutkens

By the way, this is just what my read on the terminology / naming is with these topics - I could also be wrong! Happy to learn here.

[eric-burel]

Hey @karlhorky, thanks for the valuable feedback.

At the moment this Twitter thread (which helped me a lot to write this article) doesn't really define createServerContext, I couldn't find info about that. However this server context would probably be related to the one I am talking about here, since it's a way to carry server context around in React server components.

My reasoning here for the "context" part is that in Next.js 12, you had a ctx argument in getServerSideProps which is indeed a server context, you also find this concept in GraphQL and in particular Apollo server. We talk about "contextvars" in Python too. cache and fetch are direct replacers and abstract away this context, but it still exists under the hood.

The "Next.js Cache" wording has been introduced slightly after we've published this article, which I started preparing quickly after the official release of 13.0. It might be a good naming, it's probably the same concept as the server context I mention, however it's also not documented enough so I can't fully confirm.

Possible alternatives could be "request context", "request cache", "server cache", but they feel more ambiguous, in particular this cache can also be used during static rendering so without request (or more precisely with a fictious request but that's not how people understand it).
My top and foremost argument for the "server context" naming is that in my experience that's how people will call it on Next.js Discord or on Stack Overflow: "I want React context, but server-side" -> therefore it felt relevant to me to distinguish client context and server context.

By the way there will probably be a follow-up article describing Next.js implementation of server-side caching with AsyncLocalStorage when Next.js code is more stable, I've started exploring it and it's extremely interesting, it could also be a good occasion to iterate on the naming if needed.

cc @gracemiller23 who is the naming expert here :)

[karlhorky]

However this server context would probably be related to the one I am talking about here, since it's a way to carry server context around in React server components

I think this is where our understandings of ServerContext diverge. I believe ServerContext is meant to pass information across the Server Component -> Client Component boundaries, which makes it a bit of a different concept to the one that you have in the article. I also haven't looked in depth at createServerContext and how it works, although there may be some good examples in the integration tests for React and/or Next.js. I may be able to go through these in the coming days to collect more information to present here.

It seems to me that the word "context" is a loaded word in the React ecosystem, since it most commonly refers to React Context - passing information down through multiple component layers without too much ceremony. This also is closer to React ServerContext - if my understanding is correct - although ServerContext is also across Server-Client boundaries. Both Context and ServerContext are parts of React - one type of context.

The second type of context (like AppContext, GetInitialPropsContext, GetServerSidePropsContext) is part of Next.js. These examples are less about passing information down through component layers - they contain request and response data.

This second type of context is not referred to often anymore in the beta docs, which probably lends itself at least partly to the new design of Server Components and Route Handlers (the successors to API Routes), which do not receive all of this same information. However, the dynamic route parameters are still contained within an object called context.

I wouldn't be too surprised to see these examples of the second type of context get renamed over the next versions of Next.js too, to disambiguate and move away from the loaded word "context".

Based on this and my current understanding, the generic name "server cache" feels like the closest to what the article is describing, unless you find out that Next.js Cache is indeed describing the same thing, in which case this would be the better name.

[eric-burel]

Thanks those are great insights, I think what I'll do is that I'll wait a bit that things get figured more precisely in Next, and if the wording ends up being indeed confusing we may add a banner in the article/this repo and explain the evolution of Next.js more precisely in a second article.

I do not make a difference between the two types of context you mention, as to me the server context is both:

• it's the good old GetServerSidePropsContext but now available in all RSC, not just pages (and with many differences too to be fair)
• and since it's available between RSC, it is also the server equivalent to React client context, that's where you can pass data around

What bothers me with "cache" is that it doesn't have this notion of scope, in the first place I didn't figure that React 18 cache was scoped to the current request. A context is akin to a cache (eg you load the current user once for all there) but carries this notion of scope better, especially if you come from the GraphQL ecosystem.

The wording has indeed disappeared from Next.js doc so that's why I really take your feedback into consideration, right now I am trying to fill a gap but I know that big changes are expected and will come with more precisions. I'll try to follow the news.

If a new kind of context that can cross boundaries is released, that would be awesome. However I hope it will be called something more explicit like "CrossContext" or "IsoContext" or whatever.
In particular because contrary to either a pure client-side or a pure server-side context, it will have to carry only serialized values (unless Next.js really brings much more magic than I expect in this area 👀).

Exciting times ahead either way :)

[karlhorky]

If a new kind of context that can cross boundaries is released, that would be awesome

Oh I forgot this is actually included in the tweet from Sebastian that I posted in the original issue description at the top of this page:

• https://twitter.com/sebmarkbage/status/1587615489605369861

If that's inconvenient you can use ServerContext but it must be tiny. E.g. a short string. It gets sent back and forth between Server/Client. This can be read on the client too.

let Lang = createServerContext("lang", "en");
...
<Lang.Provider value={…}>
...
use(Lang)

Another example can be seen in the test here.

In the Next.js codebase, the react-server-dom-webpack-server.edge.development.js file also has a few references to "server context", all which refer to ServerContext / createServerContext:

• https://github.com/vercel/next.js/blob/0c0318e75bd3ba3917b576dbe904389245c63949/packages/next/src/compiled/react-server-dom-webpack/cjs/react-server-dom-webpack-server.edge.development.js#L1148-L1155

So with Next.js and also React, there are a few signals which seem to show that "Server Context" will refer to ServerContext / createServerContext, for passing information across Server Component -> Client Component boundaries.