Improve ability to load messages on the client side, automatic tree-shaking of messages & lazy loading

[amannn]

(repurposed from an older issue that was solely about lazy loading)

Messages can either be consumed in Server- or Client Components.

The former is recommended in the docs, as it has both performance benefits as well as a simpler model in general since there is only a single environment where code executes. However, for highly interactive apps, using messages on the client side is totally fine too. The situation gets a bit hairy when you need to split messages based on usage in Client Components (e.g. by page, or a mix of RSC / RCC).

Ideally, we'd provide more help with handing off translations to Client Components.

Ideas:

1. User-defined namespaces
2. Manually composed namespaces
3. Compiler-based approach

(1) User-defined namespaces

This is already possible (and shown in the docs), but unfortunately not so maintainable. For single components it can be fine however, so when you have many small interactive leaf components, this is quite ok.

(2) Manually composed namespaces

This worked well for the Pages Router and was documented, but unfortunately doesn't work with RSC.

Apollo has a similar situation with static fragments: apollographql/apollo-client-integrations#27

Since namespaces are only known in Client Components, they should be able to initiate the splitting, but they mustn't have received all possible messages at this point.

This can probably be realized if you expose an endpoint where translations can be fetched from. I've experimented with using Server Actions, but they can't be used during the initial server render in Client Components. SSR would be required though.

(3) Compiler-based approach

This is explored in #1 (see #1 (comment)). Similar to Relay, if the collection of namespaces happens at build time, we could provide this list to Server Components. The experimentation here hasn't progressed far yet, this is a bit further in the future.

---

This situation shows again, that staying in RSC will always be the simplest option. So if that's a choice for your app it's, certainly the best option.

[amannn]

Maybe messages can be rendered exclusively on the server: #1 (comment)

[cdaringe]

Lazy loading is an option, but perhaps ideal is per_locale client side chunks. Rather than a common JS chunk for a page/component, instead locale-based static/* assets may be pre-built for each locale, meaning thin assets and no racing downloads or text flashes!

[mismosmi]

one could use next/dynamic for this:

One would need to wrap each locale file for each component in a NextIntlProvider. Then the component rendering that NextIntlProvider can be lazy loaded usind next/dynamic. This way next will still include the messages in the SSR'd html.

[amannn]

next/dynamic can be used to lazy load client code for a React component. But how would you integrate that with fetching the messages for a particular locale? I think with React 17 you'd still need useEffect for fetching messages lazily. Being able to pass additional messages to the provider would definitely be an interesting addition though.

I hope that future versions of React with Suspense for data fetching will help out here.

[mismosmi]

you could to something like

const i18n = {
  'en-US': dynamic(() => import('./en-US')),
  'en-CA': dynamic(() => import('./en-CA')),
  ...
}

function MyComponent() {
  const { locale } = useRouter()

  const IntlProvider = i18n[locale]

  return <IntlProvider><InnerComponent /></IntlProvider>
}

where en-US.js contains something like

export default function EnUsIntl({ children }) {
  return <NextIntlProvider locale="en-US" messages={{ ... }}>{children}</NextIntlProvider>
}

[mismosmi]

Wrap that pattern in a couple of HOCs and you end up with

// en-US.js
makeI18n({
  MyComponent: {
    title: "bla",
  }
})

// index.js
export default withI18n(() => {
  const t = useTranslation("MyComponent")
  ...
}, { 'en-US': dynamic(() => import('./en-US')), ... })

[amannn]

But that would require you to load messages for unused locales as well, right? Also I think the messages would only be loaded as soon as the module code is evaluated, so you'll probably have a null pointer if the component renders too soon.

[mismosmi]

to my understanding, dynamic does not load anything until the dynamic component is rendered so only the active locale providers would be loaded.

The messages would therefore be loaded whenever the component renders for the first time (as they are part of the lazy loaded modules) and that first time is either during the SSR step or after immediately after client side navigation (I'm not sure though if next/dynamic deals with react's suspense the same way React.lazy does)

[amannn]

dynamic does not load anything until the dynamic component is rendered

I also think that's true, but it assumes that what you're wrapping with dynamic is a component. It will either return null or a loading placeholder until the module is loaded. So it's different from suspense in that it has to render immediately and doesn't suspend until all lazy loaded modules are available. That's at least my understanding.

[mismosmi]

Yeah you might have to manually handle the loading state. Blank should be fine for most cases though as nextjs

• renders dynamic components during SSR so SEO is fine
• is pretty smart about pre-loading stuff (which might mean it will pre load all locales in most cases, I'd have to expirement with it to figure that out)

[amannn]

During the Next.js Conf this week, the Vercel team has shown a brief demo on how data could be fetched at a component-level at arbitrary levels in the tree. This approach would come in really handy for lazy loading messages, potentially from a provided API route.

This approach would also be compatible with the now suggested approach for splitting messages by namespace:

next-intl/packages/example/src/pages/index.tsx

Lines 24 to 29 in a168021

	// The namespaces can be generated based on used components. `PageLayout` in
	// turn requires messages for `Navigation` and therefore a recursive list of
	// namespaces is created dynamically, where the owner of a component doesn't
	// have to know which nested components are rendered. Note that this approach
	// is limited to components which are not lazy loaded.
	Index.messages = ['Index', ...PageLayout.messages];

Components would still define their namespaces, but lazy loaded components would be wrapped in a provider that fetches the relevant messages and adds them to the provider.

An open question is however how this would integrate with server/client components. The easiest case is if only server components need messages, but I'm not sure yet how the transition to client components could work if they need messages. Potentially also client-only components could use the new data fetching wrapper and trigger the nearest suspense boundary.

[mismosmi]

I assume it would be possible to use a server component to fetch some i18n data and then a isomorphic component to provide it as context

// locale/Common.server.tsx
export const CommonMessages = ({ children }) => {
  const { locale } = useRouter()
  const messages = JSON.parse(fs.readFileSync(`./${locale}.json`))
  return <I18nProvider messages={{ common: messages }}>{children}</I18nProvider>
}

[mismosmi]

Then you might wrap any component that needs the 'common' messages within this component and it would be passed the right messages like provideI18n(CommonMessages, ...)(MyComponent).
Then one would only have to take care that each set of messages is only transmitted once (first time the message provider is rendered), that should be doable though.

[mismosmi]

How the I18nProvider works depends a bit on how the react team will implement the context api for server components