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 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 {locale} = await params();

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).

[eric-burel]

I am still digging this issue, and I feel like we would benefit from a kind of shared context, but that would allow different value client-side and server-side.
The shared part would specifically be the accessor function, but the context provider and the value stored in it could change depending on whether you are rendering server-side and client-side.

What led me to this idea:

• Server-side, we can carry the full dictionary around with barely any performance penalty. What we do with cache. But client-side we may want to filter only the tokens we use.
• We can have 2 different systems, fine, this works. Like a ServerTrans and a ClientTrans component to display messages.
• But then what about "shared" component, that are neither client components or server-components? You have no choice but to pick either ServerTrans or ClientTrans, usually you'd favour the latter since client components can render everywhere but server components can't. You can also pass translations via props from the parents but this defeats the purpose of having contexts.

API would be:

import { getSharedIntlContext, SharedIntlContext } from "./Intl"

// A React Server Component layout
async function ServerLayout({children) {
const translations = await getTranslations()
const clientTranslations = filter(translations, clientTokens)
return (
  <div>
   {/* These translations are only available to server components */}
    <SharedIntlContext translations={translations}>
      <SomeServerComponent />
      <ClientLayout translations={clientTranslations} />
   </SharedIntlContext>
</div>
)
}

function ClientLayout({children, translations}) {
  // these translations are only available to client components
  return <SharedIntlContext translations={translations} children={children} />
}

// Display a translated message
// It will pick either the server context or the client context
// depending on where it's used
// There are 2 contexts, but only one shared accessor function
function SharedT({token}) {
  // sharedIntlContext() should work
  // client-side and server-side
  // but could return a different value
  // depending on the environment
  const { translate } = getSharedIntlContext()
  return <span>{translate(token)}</span>
}

The naming is not great but I hope you follow my point.

[amannn]

Note that you can use the react-server export condition to fork the implementation for Shared Components if you have a separate strategy for the server and client side (see useTranslations in next-intl).

[eric-burel]

That's a very smart trick, congrats on finding that. So I've tried to dig the code and check the documentation, it mentions that this shared approach works only for sync components. I guess you are expecting the messages to be available synchronously then? I see .json files in the docs so I guess you just import the messages at some point, using a synchronous import.

My problem is that the logic I've implemented that gets the messages in RSCs have to be async, because in the end it loads the messages using an API call. I could download the messages first hand and then build the app, Paraglide seems to do that too, but it's not great in a multi-tenant content where the available translation tokens may vary (for the State of JS 2023 and the State of CSS 2023, the tokens won't have the same keys). It's also non-idiomatic of frameworks that include data fetching logic exactly for this purpose, being able to render based on dynamic data.

Also you need a separate package to implement this strategy, not a blocker but having something built-in the framework would be better, even if the only use case ends up being implementation.

I think there is a progression margin in how React handle leaf components like translated text.

[markomitranic]

@eric-burel afaik the next-intl json import is an async action. I'm not an expert, but just looking at my own code:

export default getRequestConfig(async ({ locale }) => {
  if (!Object.keys(localeToLanguage).includes(locale)) {
    throw new Error(`Invalid locale ${locale} provided for translation file matcher.`);
  }

  return {
    messages: (
      await import(`../messages/${localeToLanguage[locale as keyof typeof localeToLanguage]}.json`)
    ).default,
  };
});

So i could easily fit a fetch call there if needed - but it only gets resolved once, during root layout generation. Sorry if this isn't what you were reffering to :D

[amannn]

@markomitranic Yep, that's correct!

Messages can be loaded asynchronously and from any data source. In case useTranslations is called in a Shared Component during the RSC render, the promise is resolved with the use hook and the component suspends until the messages are loaded. Note however that the promise result is cached, therefore this can happen at max. once per RSC render and can even have a slight perf benefit over async/await (see also Should I use async or non-async functions for my components?).

[amannn]

but it's not great in a multi-tenant content where the available translation tokens may vary (for the State of JS 2023 and the State of CSS 2023, the tokens won't have the same keys)

Yep, good point! I agree there are valid cases for fetching translations dynamically!

Also you need a separate package to implement this strategy, not a blocker but having something built-in the framework would be better, even if the only use case ends up being implementation.

Haven't tried it yet, but can you add a package.json within a regular folder in your project where you define the condition?

[sahandsn]

would love to see this resolved

[franky47]

There's a solution for this in nuqs for search params, and it turns out it works just fine for params too. As a bonus point, you get type-safety for non-string params:

// /blog/[date]/[slug]/page.tsx
import { 
  createSearchParamsCache as createParamsCache,
  parseAsIsoDateTime,
  parseAsString
} from 'nuqs/server'

type PageParams = {
  // Those are async in Next.js 15
  params: Promise<{ date: string, slug: string }>
}

const paramsCache = createParamsCache({
  date: parseAsIsoDateTime,
  slug: parseAsString
})

export default async function Page({ params }: PageProps) {
  paramsCache.parse(await params)
  return (
    <Deeply>
      <Nested>
        <ReactServerComponent />
      </Nested>
    </Deeply>
  )   
}

function ReactServerComponent() {
  // No prop drilling: reuse the same cache reference
  const slug = paramsCache.get('slug')
  const date = paramsCache.get('date')
  //    ?^ Date
}

[iDVB]

After reading this whole issue, this method makes complete sense to me.
Seems like the most simple solution? Any issues limitations with it?
Should all pages use the same paramsCache instance? (Assuming you would create a single file that both your server components and page can reference vs in the same file as it is here?

[franky47]

The cache is only accessible on the server, for client components you would use the useParams hook (which isn't typed though).

[amannn]

As an update here, it seems like the Next.js team is working on a solution for this topic: rootParams.

Sebastian Markbåge also shared on Twitter that cache-based patterns that need to be initialized via a setter will likely break with upcoming features in Next.js (the post was later deleted, as he closed his account). Therefore once rootParams is available, I think it'll be a good idea to transition to it.

[franky47]

Thanks for the pointer, rootParams looks like a better alternative to nuqs' cache hack (which would be impacted by Sebastian's announced behaviour change).

cc @iDVB