Server components feature doesn't work with async pages

[mertafor]

Description

I'm trying server components example. Everything works fine but I need to turn my pages async since react query hydrate function requires it. Of course there might be other libraries require to use server-side promises. I couldn't find a way to work with server components without turning page into synchronous component. There is no explanation in documentation (or maybe I missed) and I couldn't find an async page example in server components example repo.

However useTranslation function throws an error if page is async :

Error: `useTranslations` is not callable within an async component. To resolve this,
you can split your component into two, leaving the async code in the first one and
moving the usage of `useTranslations` to the second one.

Example:

async function Profile() {
  const user = await getUser();
  return <ProfileContent user={user} />;
}

function ProfileContent({user}) {
  // Call `useTranslations` here and use the `user` prop
  return ...;
}

Mandatory reproduction URL (CodeSandbox or GitHub repository)

Reproduction description

Here is an example page.tsx (it works if I remove 'async' and promises) :

import Hydrate from '@/utils/hydrate'
import { prefetch } from '@/utils/prefetch'
import { useTranslations } from 'next-intl'

export default async function Home({
  params: { locale }
}: {
  params: { locale: string }
}) {
  const t = useTranslations('common')
  const queryName = 'test'
  const queryUsers = await prefetch({ name: queryName, fn: getUsersQuery })

  return (
    <div>
      <Hydrate state={queryUsers}>
        <TestQuery queryName={queryName} />
      </Hydrate>
      <Link href={`${locale}/second-page`}>{t('home')}</Link>
    </div>
  )
}

Expected behaviour

Server components might be async functions depending on the requirements. There must be a way to use useTranslations method in async pages as well.

[amannn]

The error message suggests two alternatives, have you tried them? I'll convert this to a discussion since this is a usage question.

The current architectural direction is explained in more detail here: #406 (comment)

[mertafor]

Thanks for quick reply @amannn. Sorry for posting this without reading the message properly first. Apparently awaitable getTranslations functions is the best way at the moment.

By the way App folder has become stable since next 13.4 released yesterday. Are you planning to provide a larger example that would provide a more practical way for different use cases? Such as client components, server components (both sync and async) altogether would be really helpful. Because using a provider for client-side is also being suggested in the documentation however also mentioned that it is not ideal in terms of performance.

[ddenizakpinar]

Yes this looks awesome but still I wonder why getTranslations is deprecated. Also there is a getLocal method on next-intl/server but it is also marked as deprecated. I guess I'll use getTranslations for now until useTranslations start to work on async components.

[mertafor]

Actually they're not deprecated, they're removed (as I recall). That's the very reason I decided to build my solution the other day. I updated the library early this week after one or two months of period and half of the fundamental functions were gone. This library's server components features are still in beta and apparently there will be breaking changes until there is a stable release.

But of course your question should be better addressed by the maintainer.

[DevAtHeart]

You can also get the locale from the cookie I think. I haven't extensively tested this but I did something like this and it seems to work:

export const getTranslations = async <NestedKey extends NamespaceKeys<IntlMessages, NestedKeyOf<IntlMessages>> = never>(
  namespace: NestedKey,
) => {
  const locale = cookies().get('NEXT_LOCALE')?.value ?? 'en';
  return getTranslator(locale, namespace);
};

Upon further testing, it seems this only works on the second request.

[mertafor]

Looks like a nice one @DevAtHeart. By the way there is one thing should be taken into consideration. Using headers or cookies will turn the request SSR automatically and static rendering (generateStaticParams) will be disabled, or it might throw an error. Probably that's the very reason why getLocale function has been removed (just a guess). I've heard that there is an upcoming react feature called createServerContext. I couldn't find much information about it but the name suggests it might be a serverside context for accessing params and searchparams from server components, at least that's what I hope. In my opinion it is probably the biggest missing piece of server components at the moment.

[mertafor]

I'd like to share the solution I found the other day. Actually I took the idea from an NPM package made exactly for this purpose (sorry, forgot the package's name). This actually magical for me because I've been looking for a way to get params without prop drilling.

First create a file with this :

import 'server-only'
import { cache } from 'react'

export const ServerContext = <T>(
  defaultValue: T
): { getServerContext: () => T; setServerContext: (v: T) => void } => {
  const getRef = cache(() => ({ current: defaultValue }))
  const getServerContext = (): T => getRef().current
  const setServerContext = (value: T) => {
    getRef().current = value
  }
  return { getServerContext, setServerContext }
}

export const { getServerContext, setServerContext } = ServerContext('en')

Then use setServerContext in layout.tsx to cache lang/locale param :

export default async function RootLayout({
  children,
  params
}: {
  children: React.ReactNode
  params: {
    session: Session | null | undefined
    lang: iLanguages
  }
}) {
  setServerContext(params.lang)
  ....
}

Now, you'll be able to access lang param in any server components :

export const MyServerComponent = () => {
  const lang = getServerContext()
}

The reason this method better than accessing headers or cookies is that static path generation still works. The example above only stores lang constant but probably the value could be extended with entire params and searchParams as string (with JSON.stringify). I haven't tried it since I don't know the limitations of cache method. It still might be an experimental feature.

[ClementDreptin]

Hi!

I assume not being able to use useTranslations in async component has its technical reasons but it would be so much nicer if it was possible. Having to extract some UI to different components just because they contain labels results in a strange component architecture a lot of the time.

I was trying to create a page that receives search params, fetches data according to them and renders a UI that needs to be translated. I started by doing this:

// page.tsx
const Page = async ({ searchParams }) => {
  const data = await getData(searchParams);
  const t = useTranslations();

  return (
    <div>
      {/* render UI with the dynamic data */}
      <Link href={{ pathname: "/some-route", query: searchParams }}>{t("someRoute")}</Link>
    </div>
  );
};

then I get an error telling me I can't use useTranslations in async component, so I extracted the link to another component like so:

// page.tsx
const Page = async ({ searchParams }) => {
  const data = await getData(searchParams);

  return (
    <div>
      {/* render UI with the dynamic data */}
      <SomeRouteLink />
    </div>
  );
};

// SomeRouteLink.tsx
const SomeRouteLink = () => {
  const t = useTranslations();
  const searchParams = useSearchParams();

  return <Link href={`/some-route?${searchParams.toString()}`}>{t("someRoute")}</Link>
};

Now I get an error telling me I can only use useSeachParams in client components, so instead of getting the URL search params with the hook, I pass them to the SomeRouteLink component as props. Ending with something like this:

// page.tsx
const Page = async ({ searchParams }) => {
  const data = await getData(searchParams);
  const t = useTranslations();

  return (
    <div>
      {/* render UI with the dynamic data */}
      <SomeRouteLink searchParams={searchParams} />
    </div>
  );
};

// SomeRouteLink.tsx
const SomeRouteLink = ({ searchParams }) => {
  const t = useTranslations();

  return <Link href={{ pathname: "/some-route", query: searchParams }}>{t("someRoute")}</Link>
};

In my experience, this limitation adds unnecessary layers of complexity that could be avoided if I could just use useTranslations in async components. This might not seem like much because the example above is over-simplified. In the real codebase, the limitation has other annoying side effects.

I'm sure this limitation has its reasons but I hope you consider removing it in the future.

[amannn]

Thanks for taking the time to explain your situation! I agree 100% and would be happy if this restriction can be lifted from React.

Please note that this is a constraint from React that next-intl has to live with for the time being: facebook/react#27045

I do hope that this constraint will be removed in the future.

[ClementDreptin]

Oh, I didn't know the limitation came all the way from React. I just tried with useRouter from Next.js and it spits the same error.
Using Next.js 13, the app directory and server components has been amazing so far and simplifies so many things, but the support for external tools and especially styling solutions is a little rough right now. I hope things get better soon!

[bernhardw]

Thanks for taking the time to explain your situation! I agree 100% and would be happy if this restriction can be lifted from React.

Please note that this is a constraint from React that next-intl has to live with for the time being: facebook/react#27045

I do hope that this constraint will be removed in the future.

But does useTranslations() really need to be a React Hook when I only use Server Components? ... or is it just treated as such because of the use prefix?

Many of our Server Components are async, because of the recommended granular data fetching and they all need access to the messages.

[amannn]

The error message that is shown when you try to use useTranslations in an async component shows the current recommendation:

`useTranslations` is not callable within an async component. To resolve this,
you can split your component into two, leaving the async code in the first one
and moving the usage of `useTranslations` to the second one.

Example:

async function Profile() {
  const user = await getUser();
  return <ProfileContent user={user} />;
}

function ProfileContent({user}) {
  // Call `useTranslations` here and use the `user` prop
  return ...;
}`

[bernhardw]

Sorry, that was obvious to me, but not to others. I meant something like getTranslations(), usage without Context etc. Something besides the recommendation which would mean changing the architecture of a lot of our components.

[bernhardw]

I just found out about const t = await getTranslator(locale); and think I can work with that to build a custom getTranslations() function.

[enrique-fernandez-polo]

It would be awesome if you share any cool code using const t = await getTranslator(locale)

I refuse to extract everything in components just because of this 😂

[bernhardw]

I decided to just use const t = await getTranslator(locale) in my Server Components and const t = useTranslations() in my Client Components... not particularly beautiful, but it works 😉

[Yedidya10]

The error message that is shown when you try to use useTranslations in an async component shows the current recommendation:

`useTranslations` is not callable within an async component. To resolve this,
you can split your component into two, leaving the async code in the first one
and moving the usage of `useTranslations` to the second one.

Example:

async function Profile() {
  const user = await getUser();
  return <ProfileContent user={user} />;
}

function ProfileContent({user}) {
  // Call `useTranslations` here and use the `user` prop
  return ...;
}`

Where can I find an extended explanation for this? In particular for TS?

One of the issues I encountered is when I split in two - i need to define/import a type of the useTranslations function.

Is there a type for this or do I have to define it myself?

I am using version 3 beta

My example code:

'use server'

import Cards from '@/components/cards/allCards/AllCards'
import Box from '@mui/material/Box'
import { useTranslations } from 'next-intl'

type TranslationsType = {
   ... ?
}

function AllItemsContent({ t }: { t: TranslationsType }) {
  return (
    <Box
      sx={{
        width: '100%',
        m: 'auto',
      }}
    >
      <Cards label={''} t={t} />
    </Box>
  );
}

export default async function AllItems() {
  const t = useTranslations<TranslationsType>('AllItems');

  return <AllItemsContent t={t} />;
}

[amannn]

As the error messages tries to explain, you should move the useTranslations call to the non-async component. That way you also don't have to pass and type it.

Hope this helps!

[Yedidya10]

Can you please provide an example?

If for example I write like this;

'use server'

import Cards from '@/components/cards/allCards/AllCards'
import Box from '@mui/material/Box'
import { useTranslations } from 'next-intl'

export default async function AllItems() {
  return <AllItemsContent />
}

function AllItemsContent() {
  const t = useTranslations('AllItems')

  return (
    <Box
      sx={{
        width: '100%',
        m: 'auto',
      }}
    >
      <Cards label={''} t={t} />
    </Box>
  )
}

I still get an error:

error Error: Functions cannot be passed directly to Client Components unless you explicitly expose it by marking it with "use server".   
  <... label="" t={function}>

[amannn]

It's caused by the t prop you're passing to Cards. You can avoid the error by not passing t anywhere and always generating it within a component body via the hook!

[laurent512]

Any clean outcome of this discussion? :) The two solutions proposed by default in the error message are quite inconenient to me

[ngalioth]

I think it's about the fact that the use() api is only available in experimental and canary channels.I am using

• react 18.2.0
• next-intl 3.0.0-rc.4
• next 13.5.4
  After manually enable the experiemental flag ppr:true in next.config.mjs, useTransitions() in async rsc works

[J4v4Scr1pt]

Nice, gonna try it out.

I did like someone above suggested as a temp fix:

const headersInstance = headers();
const locale = headersInstance.get('X-Locale');
const t = await getTranslator(locale || 'en-US', 'home');

Ugly.. yes.. but it works for now.

[FelipeJz]

Sure, there are workarounds. I hope this becomes a priority in the future as we delve deeper into this new paradigm.

[amannn]

For those following this issue, I've added a comment in #406 to explain the current architectural direction in more detail, hope this helps!