[Docs]: Update Typescript Integration docs

[ayhankiz]

Link to page

https://next-intl-docs.vercel.app/docs/workflows/typescript

Describe the problem

My problem is following: I want to pass down the translation function as a prop, but i don't know how to achieve the type of it.

Thats my type i created so far:

export type Translations = Awaited<ReturnType<typeof getTranslations>>;

This works but only if i have one key in my messages.json. If i have multiple keys it doesn't work.

I put it under docs, because i hoped that i will find a way to achieve this by reading the docs.

[amannn]

This is currently not supported by design: #92

Can you solve your problem with something like this?

const t = useTranslations('Global');

function getLabel(key: 'key1' | 'key2' | …) {
  return t(key);
}

<BrickRenderer getLabel={getLabel} />

[ayhankiz]

I expressed myself incorrectly i guess.
I think it helps if I show you the structure of my en.json file

{
    "Form": {
        "firstnamePlaceholder": "Test",
        ...
    },
    "Users": {
        "someKey": "value",
        ...
    },
    "Global": {
        "anotherKey": "value",
        ...
    },
}

And now for example i want to pass down the t() function with the key "Global" to the component renderer (brick renderer).
But when I call the t() function I get all the values of users and form as well (autocomplete) although I only want the values of global.

e.g:

Only someKey should be shown. I hope i expressed my self this time better :)

[amannn]

That's because this type doesn't work as expected:

export type Translations = Awaited<ReturnType<typeof getTranslations>>;

The reason why passing the t function around isn't supported is currently about type safety, but there's work happening on automatically detecting which key is used where to automatically split messages for certain parts of the tree (see #1).

If {use,get}Translations is used in the same component as t, then we can infer which messages are used in this component. If that isn't the case (e.g. t(someVar)), we have to provide all messages within a given namespace (depending on your situation arguably also ok, but something that shouldn't be the first thing you're reaching for).

Can you tell me a bit more about your BrickRenderer? Is passing final labels like headline={t('headline')} also an option or do you need to pass variables to the t function? If so, are they not accessible to the parent? Could this be solved by adapting the component structure?

I understand that this constraint on the usage of t is somewhat limiting, but I hope that it puts us in a good position in the long run.

I'll move this to a discussion for the time being, since this is currently working as expected.

[ayhankiz]

The Brickrenderer (Component-Renderer) basically just renders the components inside the CMS.
Lets say the user added Comp1, Comp2, Comp3 inside the Homepage and the Brickrenderer renders:

<>
<Comp1 {...props} />
<Comp2 {...props} />
<Comp3 {...props} />
</>

Actually it's not necessary to pass down the t function to my components but my concern is the performance.
Let's say I have a page which has 20 Components and 10 of the Components need to access the t() function, now i have to call in every Component (which needs the messages) await getTranslations(key).

And with the BrickRenderer i can just pass down the t() function and only call the function once.

Maybe my concern isn't necessary, what do you think?

[OFranke]

@ayhankiz
You can achieve it like that:

// messages/de-DE.json

{
  "forms": {
    "validation": {
      "email": "is required"
    }
  }
}

// types/next-intl.d.ts
import message from '../../messages/de-DE.json';

type Messages = typeof message;

declare global {
  // Use type safe message keys with `next-intl`
  interface IntlMessages extends Messages {}
}

use it like this:

type TranslationKeys = 'forms.validation';
type TranslateFunction<T extends TranslationKeys> = Awaited<
  ReturnType<typeof getTranslations<TranslationKeys>>
>;

function passedTranslateKeysFunction(t: TranslateFunction<TranslationKeys>) {
  return t('email'); // will give correct type hints
}

async function callTranslateFunction() {
  const t = await getTranslations('forms.validation');
  passedTranslateKeysFunction(t);
}

Like that, everything should suggest correct typing

[dBianchii]

This looks promising. But how can we type the TranslationKeys to be a list of all possible key combos? Like "forms" | "forms.validation" | "errors" ... etc?

[dBianchii]

Another problem I see about passing the t as an argument, is that i18n-ally will not work properly

[dBianchii]

Here's an example of i18n-ally not working, after I correctly typed the t function to be in the scope of "validators":