Drawbacks of manually supplying messages to context provider over using getMessages?

[ChristianIvicevic]

I am in the process of splitting up my i18n file into server and client files to reduce the amount of strings sent to the client as well as keeping certain strings on the server in order to not have them accessible by data mining. My setup is fairly simple as follows:

// global.d.ts
type ClientMessages = typeof import('@/i18n/en.client.json')
type ServerMessages = typeof import('@/i18n/en.server.json')

declare interface IntlMessages extends ClientMessages, ServerMessages {}

// request.tsx
export default getRequestConfig(async () => {
  // ...
  return {
    // ...
    messages: {
      ...(await import('@/i18n/en.client.json')).default,
      ...(await import('@/i18n/en.server.json')).default,
    },
    // ...
  }
})

// layout.tsx
const getClientMessages = cache(async () => (await import('@/i18n/en.client.json')).default)

export default async function RootLayout({ children }: { children: ReactNode }) {
  // Is there any differences/drawbacks using my second approach to hide server variables?
  const messages = await getMessages()
  const messages = await getClientMessages()

  return (
    {/* ... */}
    <NextIntlClientProvider messages={messages}>
      {children}
    </NextIntlClientProvider>
    {/* ... */}
  )
}

As the comment in the layout suggests, I'd like to ask whether there is functionally any difference between the two lines in the layout that I should be aware of.

In terms of DX I am aware of the typing not being narrow enough or rather not contextual enough to display only client/only server variables, but I've written a small tool that "lints" my use of variables based on context and complains in case I do something wrong as such I'm only curious about the use of my function in the layout.

[amannn]

Your approach with passing messages from getClientMessages is absolutely fine!

There's a bit more about this here:

1. Using internationalization in Client Components
2. Configuration: Client- and Server Components

The ultimate goal would be to automatically detect which messages are needed for the client side btw.: #1.

Is your tool that lints for client messages available somewhere? Or can you briefly explain how it works? Would be curious :)

[ChristianIvicevic]

Glad to hear that my approach makes sense!

As for the tool, I only recently put it together, but you can take a first look here.

The script uses ts-morph to analyze calls in the following forms, and it tracks whether t (or whatever name users choose) originates from calling useTranslations or getTranslations. This allows it to partition the strings into server or client messages:

t('literal')
t(identifier) // identifier must resolve to a literal or a literal string union
t(`prefix${identifier}suffix`) // only one part is currently supported, and the resulting key must be statically analyzable

Since I'm using this for my own project, it doesn't support more complex expressions like t(condition ? key1 : key2), which would need to be rewritten as condition ? t(key1) : t(key2), similar to how Tailwind tracks class names.

I’ve been thinking about cleaning up the code and making it modular, so that different behaviors could be integrated when the script encounters specific references. Eventually, I plan to publish it, but it will take me a few days to package it properly with sufficient tests.

Regarding your feature for introducing tree-shaking, this is a simplified version that works for my personal projects so far.

[amannn]

Oh I see, so in your case you're using useTranslations exclusively in Client Components and getTranslations exclusively in Server Components—right? That's an interesting simplification that enables this approach I guess.

I tend to recommend useTranslations also for shared components that work in either environment (see non-async Server Components). The PoC mentioned in #1 works by traversing based on client-side module graphs in contrast.

But your approach is certainly interesting and seems like it already works. So definitely leave a note in #1 in case you publish it :)