Best practice for NextIntlProvider - get messages from i18n/request.ts vs fetch within app/layout.tsx #1373

vasanthid · 2024-09-26T18:45:36Z

vasanthid
Sep 26, 2024

Hi,

First of all, congratulations on providing such an awesome library. After evaluating few i18n libraries on various factors, we decided to go with next-intl for localization feature within our project.

However, I would like to understand the best practice here in implementation as I'm new to Next.js (app router) and also still learning next-intl.

Context:
We have a Next.js 14.2.10 and we are using app router, also using the latest next-intl 3.19.4
Our app still uses client side components. That is, 'use client' in app\page.tsx (We may change this in future to move to RSC but not in plans yet).
And, we need to implement localization without "i18n routing"
I followed the example for a proof-of-concept example-app-router-without-i18n-routing and it works great.
Only difference is that we'll not be reading the locale from a cookie instead from a API call made client side after user is authenticated.

Questions:

As per docs "i18n/request.ts can be used to provide configuration for server-only code, i.e. Server Components, Server Actions & friends. ",

Since our project has only client side components, I'm thinking I can get the messages in /layout.tsx for NextIntlProvider in two ways.

Option 1: Use i18n/request.ts --> getRequestConfig to load messages (as showed in the example-app-router-without-i18n-routing example ). This works in my testing with our app with 'use client' in app\page.tsx.

app/layout.tsx

import {NextIntlClientProvider} from 'next-intl';
import {getLocale, getMessages} from 'next-intl/server';

export default async function LocaleLayout({children}: Props) {
  const locale = await getLocale();

  // Providing all messages to the client
  // side is the easiest way to get started
  const messages = await getMessages();

  return (
    <html lang={locale}>
      <head>
        <title>next-intl example</title>
      </head>
      <body>
        <NextIntlClientProvider messages={messages}>
          {children}
        </NextIntlClientProvider>
      </body>
    </html>
  );
}

Option 2: Exclude i18n/request.ts file altogether and fetch the messages on client side within app\layout.tsx. This method will not use {getLocale, getMessages} from 'next-intl/server';

app/layout.tsx

import {NextIntlClientProvider} from 'next-intl';

export default async function LocaleLayout({children}: Props) {
  const locale = await getLocale(); // use service all or a react hook (like react query hook to get locale)

  // load messages on the client 
  let messages
  try {
    messages = (await import(`../../messages/${locale}.json`)).default
  } catch (error) {
    console.error('Failed to load messages:', error);
  }

  return (
    <html lang={locale}>
      <head>
        <title>next-intl example</title>
      </head>
      <body>
        <NextIntlClientProvider messages={messages}>
          {children}
        </NextIntlClientProvider>
      </body>
    </html>
  );
}

I'm not very sure if I'm thinking in the correct direction here. Can I use either of the options? If so, which one is recommended and best practice given we have all client side components and prefer to read user's locale from a react-query hook?
For my own understanding, is there a need/requirement to use i18n/request.ts -> getRequestConfig if an app is using mostly client side components with state dependency?

Also, what is the difference between getMesssages vs useMessages
From docs, I see useMessages() for regular components or getMessages() for async server components.
Does useMessages get messages from i18n/request.ts --> getRequestConfig?

amannn · 2024-09-27T12:14:41Z

amannn
Sep 27, 2024
Maintainer

Interesting question! Yep, both approaches are fine. If there's no preference from your side, I'd go with i18n/request.ts, just to make it easier in case you add any server-only code in the future. This doesn't necessarily need to be a Server Component, but could for example also be a Route Handler etc.

Hope this helps!

4 replies

vasanthid Sep 27, 2024
Author

@amannn - Thank you so much for your response. It sure helps. I agree to go with i18n/request.ts for the same reason you mentioned.

Could you elaborate little bit on the difference between getMesssages vs useMessages.
From docs, I see useMessages() for regular components or getMessages() for async server components.
Does useMessages get messages from i18n/request.ts --> getRequestConfig?

amannn Sep 30, 2024
Maintainer

Yep, if you call useMessages in a Server Component, then it retrieves the messages from i18n/request.ts! If the hook is used in a Client Component, then it retrieves the messages from context (i.e. what was set on NextIntlClientProvider).

vasanthid Oct 1, 2024
Author

@amannn - Thank you for your response.

Wouldn't we use useTranslations hook in client components to read the messages from context (i.e messages set on NextIntlClientProvider) ?
If useMessages in a Server Component retrieves the messages from i18n/request.ts, what is the difference between getMessages and useMessages?

Sorry to bug you on this. I'm bit confused and need some clarification. Appreciate your help.

amannn Oct 1, 2024
Maintainer

Maybe this provides some clarity: Server & Client Components (esp. the section "How does the Server Components integration work?").

Let me know if that helps!

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Best practice for NextIntlProvider - get messages from i18n/request.ts vs fetch within app/layout.tsx #1373

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 1 comment 4 replies

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

Select a reply

Best practice for NextIntlProvider - get messages from i18n/request.ts vs fetch within app/layout.tsx #1373

vasanthid Sep 26, 2024

Replies: 1 comment · 4 replies

amannn Sep 27, 2024 Maintainer

vasanthid Sep 27, 2024 Author

amannn Sep 30, 2024 Maintainer

vasanthid Oct 1, 2024 Author

amannn Oct 1, 2024 Maintainer

vasanthid
Sep 26, 2024

Replies: 1 comment 4 replies

amannn
Sep 27, 2024
Maintainer

vasanthid Sep 27, 2024
Author

amannn Sep 30, 2024
Maintainer

vasanthid Oct 1, 2024
Author

amannn Oct 1, 2024
Maintainer