SSR: multiple i18n instances vs calling loadAndActivate per request?

[pepijnvandenhoven]

I stumbled into an issue with Next.js SSR and came across a related issue here. It refers to the example over here.

I was wondering if there are any suggestions on the note that's in the useLinguiInit hook?

if (!isClient && locale !== i18n.locale) {
  // there is single instance of i18n on the server
  // note: on the server, we could have an instance of i18n per supported locale
  // to avoid calling loadAndActivate for (worst case) each request, but right now that's what we do
  i18n.loadAndActivate({ locale, messages });
}

Is it really preferable to have an instance per locale over calling loadAndActivate per request? And if so, how would I set that up?

[thekip]

Yes, it's preferable to have an instance per request. And this instance should be passed to the React tree and never used globally. Keep in mind that macro such as t or plural using i18n instance globally if you haven't pass it explicitly like so t(i18n)`Hello!`.

The main gotcha with Server-side VS Client-side - your server process few requests simultaneously. And if you have any async jobs during the response (and you do have, because it's almost impossible to write an app without async) the one request may affect response of other requests.

Imagine the example with one global instance:

1. Server receive [request 1] with EN language. loadAndActivate('en') is called
2. Server renders couple of strings with 'en' language, and start fetching some async data
3. While server waited for an async operation to complete it received [request 2] with ES language and loadAndActivate('es') was called
4. After completion of async operation for [request 1] the global instance switched to ES language and rest of the messages would be in ES.

I believe initial design of Lingui was created when more SPA application was developed, now we see a shift towards MPA application with SSR rendering and concepts from original design become confusing for people.

[pepijnvandenhoven]

Ok, I get the issue now (thought it was performance related). How can I pass the instance to the client/React tree then?

[thekip]

When you instantiate I18nProvider it passes the instance to the react tree. Then using useLingui hook you can get instance for use with t macro. Trans macro uses instance from provider automatically.

[pepijnvandenhoven]

Thank you for your help and quick responses. I think I figured it out :)

[thekip]

I've just discovered an AsyncLocalStorage in nodejs which created to solve this exact issue. See this talk https://www.youtube.com/watch?v=R2RMGQhWyCk&t=9742s