Reading params deeply in Server Components (e.g. for i18n / multi-tenancy)

[amannn]

Apps that use i18n or multi-tenancy are typically implemented with a top-level dynamic segment like [locale] or [market] (or a combination of both). Currently, to be able to use the value of these segments in Server Components, the only way is to read them in a page or layout from props and pass the values down to the components where they are needed (see e.g. the Next.js i18n example).

While this can work for some apps, it can become quite cumbersome if many components are implemented as Server Components and require param values. My personal observation is that especially content-heavy apps can be implemented with a large number of components being Server Components. In the case of i18n, most components require the locale argument, therefore the developer would have to pass this value through almost all layers of components.

To mitigate this, i18n libraries like next-intl and next-international have introduced workarounds to pass a locale as a request header from the middleware to Server Components. While this improves the ergonomics, it opts all pages into dynamic rendering by default. Due to this, these libraries also provide cache()-based workarounds like unstable_setRequestLocale in next-intl and setStaticParamsLocale in next-international to be able to bring back static rendering capabilities. While this works, it's arguably a bit cumbersome too and requires special care from the developer.

I previously had some hopes that ServerContext could work for this use case, but this API was removed from React. There was a note from @sebmarkbage in the related PR that deprecated the feature though:

There are perhaps other new features that frameworks can provide (like maybe Next.js can give access to part of the URL like i18n) that can be specific solutions to specific problems.

It would be very helpful if Next.js would provide a way to read the params that are passed as props to pages and layouts deeply from within the tree. The necessary constraint would be that only params from the current and parent segments can be read (same as the params prop).

Example API:

// Same as `params` in the active segment
const params = getParams();

Related discussions:

• [Next 13] Server Component + Layout.tsx - Can't access the URL / Pathname #43704
• How to get dynamic route params from Server Components? #51818
• A way to access the params and pathname in all server components #46618

Thank you for your consideration!

EDIT: Here are some notes from an analysis I did on the implementation: #58862 (comment).

[apavlinovic]

We have this exact use case, and it is cumbersome. It would be great if we could remove the unstable_setRequestLocale calls and let react-intl handle this. +1 on getting an official API to get the current route params server side.

[AhmedBaset]

Related: PR #59909 provides a new similar API getPathname().

[stefanprobst]

@leerob can you clarify what the thoughts/plans of the team are in regards to this? thanks!

[AhmedBaset]

take a look at https://github.com/vordgi/next-impl-getters/blob/main/src/get-params.ts

I think it would be a better stopgap than our setRequestLocale

[amannn]

Interesting, thanks for sharing! It uses internals from Next.js, I'd be a bit worried about this breaking randomly between non-major Next.js versions (seems like there were such changes already), but it's interesting to see that this works.

[markomitranic]

@amannn interestingly they seem to be awaiting a PR merge into nextjs with that.

offtopic: More interestingly, their library seems to use AsyncLocalStorage for a server-context-like behaviour instead of cache. I wonder why and what is the difference. Do you happen to know?

[dferber90]

@markomitranic cache is not available in middleware, but AsyncLocalStorage is

[markomitranic]

Thanks for your answer @dferber90 !

I would be very careful with coupling the middleware/proxy execution to the layout or page render on a given machine or node process. There is a good reason why proxies only communicate through standardized systems - redirection, routing, url or header manipulation.

[parsasabetz]

[markomitranic]

Hey @parsasabetz just for context, NextJS doesn't really have much to do with this, it is a React-level decision, modeled on how this same concept works in other server side languages. Tagging leerob isn't going to help you.

Additionally, stating that it needs to be "fixed" is a bit misleading, as nothing is broken, it was a concious decision made by the React team years ago.

What next-intl is doing, is perfectly in line with what any other server framework would do - You capture the locale from the pathname, then you store it in a shared global cache, and later you access it from the global scope.

The main difference between what next-intl does versus what Symfony or Rails would do is that they don't have 3 separate execution environments that don't share cache (middleware, layout, page) and which can be executed at completely separate times. Some server frameworks, like Elixir's Phoenix take it a step further and enforce prop drilling (or stateful process) instead of shared variables.

We are perfectly capable to make server-side contexts to prevent prop drilling and even share that data with the client components. We aren't, however, able to share logic, only data.

[eric-burel]

@markomitranic the article you linked is very interesting! Just a small nitpick

We aren't, however, able to share logic, only data.

This is true for an isomorphic context that would be shared between client and server, which was the point of deprecated createServerContext. But for a pure server context based on the cache function, you can share "logic" in the form of non serializable objects. The first time I used this pattern was actually to get proper GraphQL caching using heavy clients like Apollo, with a request-scoped instance of the client being shared via cache.

[GabenGar]

My conclusion after dealing with internationalization and similar global-but-not-quite values is just accept prop drilling and pass them everywhere.
Any "convenient" solution would either chock in multi-environment/multi-threading/lambda setups or outright not be as convenient as it claims to be outside of hello world examples.
It's just an inherent problem of hybrid render since not only server and client have different globals, they also operate on different models. I.e. any client script at any given time is dealing with the context of one request, while the server constantly churns through them and renders context-dependant templates. Therefore any function accommodating both models will end up in a strict subset environment where it can't liberally use neither client nor server context. I also question the point of server components accessing route params deep in the render tree, since it creates an implicit dependency on the route which can be pretty annoying to debug and fix, especially if the component in question is overly generic (but not quite).

[amannn]

I had a quick look into what it'd take to implement this.

From my understanding, the RSC render starts here:

next.js/packages/next/src/server/app-render/app-render.tsx

Lines 949 to 959 in 0b261f0

	// We kick off the Flight Request (render) here. It is ok to initiate the render in an arbitrary
	// place however it is critical that we only construct the Flight Response inside the SSR
	// render so that directives like preloads are correctly piped through
	const serverStream = ComponentMod.renderToReadableStream(
	<ReactServerApp tree={tree} ctx={ctx} asNotFound={asNotFound} />,
	clientReferenceManifest.clientModules,
	{
	onError: serverComponentsErrorHandler,
	nonce,
	}
	)

As far as I understand, all layouts and the page that render as part of a request are all part of the tree that is passed to ReactServerApp here. This means that there is a single render call and the mechanism of rendering layouts and the page in parallel is handled by React internally.

Now the mechanism for "server context" in Next.js is based on AsyncLocalStorage. More specifically, the "context" is initialized here:

next.js/packages/next/src/server/app-render/app-render.tsx

Lines 1504 to 1510 in 0b261f0

	StaticGenerationAsyncStorageWrapper.wrap(
	renderOpts.ComponentMod.staticGenerationAsyncStorage,
	{
	urlPathname: pathname,
	renderOpts,
	requestEndedState: { ended: false },
	},

AsyncLocalStorage works by providing a value deeply to a function closure. And that makes this a bit tricky to implement.

Since there is only a single render call, I don't see an obvious place where StaticGenerationAsyncStorageWrapper.wrap could be called per rendering of layouts or pages. This is necessary though since layouts should only be able to access parent params, not potentially nested ones.

This poses the question: Should React provide a mechanism to distribute data via a context-like mechanism within Server Components since it "owns" the call to render components? The initial createServerContext proposal covered both the server as well as the client. From my experience, a server-only mechanism would be sufficient (I'd be happy with anything though).

I'm not really familiar with the Next.js codebase though, so if anyone has ideas or pointers, I'd be happy to discuss!

EDIT: Seems like ReactFizzServer has some traces of a request storage based on AsyncLocalStorage (see #58862 (reply in thread))

[amannn]

Hey @eric-burel! Yep, I've seen that post by Delba, I absolutely understand the limitation in regard to the pathname since layouts might not re-render as part of RSC requests. For layout params I believe the situation is a bit different, where the limitation seems to not be conceptually, but on an implementation level.

I'm unsure what it would take from the technical perspective though to achieve this. Makes me wonder if AsyncLocalStorage should be renderable and consumable like <SomeAsyncLocalStorage>{children}</SomeAsyncLocalStorage> and use(SomeAsyncLocalStorage)? 🤔

As a bonus (unrelated to server context) we are introducing a token expression language that helps filtering the messages we send to the client, I am going to publish articles about that when it's a bit more polished.

Sounds interesting, would be curious to follow along! Is it compiler-based, similar to what is described in amannn/next-intl#1 (comment)?

[vordgi]

@vordgi since Next.js uses AsyncLocalStorage I think at worst, a solution based on it will be as robust as Next.js itself

Problems arise during assembly, when hundreds of contexts live in parallel in a short time. Next.js uses it over processes. This minimizes risks. But tried to find a reason why sometimes node.js can lose context, but I can't (apparently the node.js developers can't find them too).

That's why I implemented page-context logic (PR).

[vordgi]

Makes me wonder if AsyncLocalStorage should be renderable and consumable like {children} and use(SomeAsyncLocalStorage)

That's what I did in @nimpl/context. You can try it, but in two projects where I tried to add this solution, it lost context with a probability of about 0.5%. As a result, I took it out into a separate package and removed it from my other packages.

[amannn]

Your implementation with storage.enterWith is interesting … Makes me wonder if that could work, or if there's a risk that the context leaks out of a part of the tree, or as you've mentioned gets lost. If yes, this might require first-class support from React, but maybe worth digging a bit further into this. Another interesting case is when part of a tree suspends, if the suspended render calls still have access to the context.

There's also this note in the docs:

That is why run() should be preferred over enterWith() unless there are strong reasons to use the latter method.

If React would support this internally, maybe it could be implemented with run(). A userland solution is probably not able to use run(), since you only own the creation of React elements, not the call to actually render them.

[amannn]

As a side note, ReactFizzServer seems to already have some usage of a request storage (which is based on AsyncLocalStorage).

[vordgi]

Made a PR with the get-params implementation (in the basic version - it's a very simple change).