withTranslation - Type error: Type 'TFunctionResult' is not assignable to type 'ReactNode' #1559

MarcelGeo · 2022-10-07T09:52:54Z

Type error: Type 'TFunctionResult' is not assignable to type 'ReactNode'

This typescript error is not fixed by using withTranslation HOC.

stale · 2022-10-15T18:19:56Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

manwaring · 2022-10-20T16:47:37Z

I'm getting the same error in the v12 release for the t function from useTranslation hook

denizguzel · 2022-10-20T17:59:49Z

Similar error here with the v12 release,

Type 'DefaultTFuncReturn' is not assignable to type 'ReactNode'.

adrai · 2022-10-20T17:59:56Z

fyi: i18next/i18next#1852

meyfa · 2022-10-20T18:29:54Z

Similar error here with the v12 release

See https://www.i18next.com/overview/typescript for how to add the required type definitions. This will make the error go away. But more importantly, i18next will now ensure you don't pass arbitrary strings to the t function that are not part of your translations. The feature was implemented here: i18next/i18next#1775

By the way, thanks to everyone who made this happen! This is awesome! Finally we can statically ensure correct usage of the t function 🎉

SergioTx · 2022-10-21T11:30:47Z

And what if you need to pass "arbitrary strings" or at least strings formed by concatenation?

Something like:

function component(props: {stringProp: string}) {
  const {t} = useTranslation(myNs);
  return <div>{t(props.stringProp)}</div>
}

To strictly type all strings with templates is not always an option.

Thank you!

meyfa · 2022-10-21T11:36:56Z

@SergioTx I think it makes sense to refactor such that the props are already translated. If this is not an option, you could use as any to evade type checking. Having the any type assertion there would at least clearly indicate to any future reader that the code is not actually safe.

florianbepunkt · 2022-10-26T07:03:07Z

Is there any way to disable type-checking here? In our translation workflow, we define the keys in code first with a default value... and then the translation keys are extracted by and automated process. So we have code-first approach when it comes to the keys, while the typescript docs effectively describe a translation-first approach, where the translation keys already exists in a JSON file.

adrai · 2022-10-26T11:28:34Z

Is there any way to disable type-checking here? In our translation workflow, we define the keys in code first with a default value... and then the translation keys are extracted by and automated process. So we have code-first approach when it comes to the keys, while the typescript docs effectively describe a translation-first approach, where the translation keys already exists in a JSON file.

i18next/i18next#1853 (comment)

chybisov · 2022-10-26T14:26:19Z

The same error with the t from useTranslation hook.

Type 'DefaultTFuncReturn' is not assignable to type 'ReactNode'.

adrai · 2022-10-27T07:53:55Z

can you try with i18next v22.0.3?

karesztrk · 2022-10-27T08:08:36Z

can you try with i18next v22.0.3?

It works now. No compilation errors.

adrai · 2022-10-27T08:23:02Z

@MarcelGeo can we close this?

kirill-linnik · 2022-10-29T13:06:22Z

I have the same problem with 22.0.4:
TS2322: Type 'DefaultTFuncReturn' is not assignable to type 'string | ReactElement<any, string | JSXElementConstructor<any>> | undefined'.
as a workaround, it looks like I should wrap all function invocation into <></>, which is a bit painful for a bit project. is there any other way fixing it?

adrai · 2022-10-29T13:09:45Z

I have the same problem with 22.0.4:

TS2322: Type 'DefaultTFuncReturn' is not assignable to type 'string | ReactElement<any, string | JSXElementConstructor<any>> | undefined'.

as a workaround, it looks like I should wrap all function invocation into <></>, which is a bit painful for a bit project. is there any other way fixing it?

Can you create a reproducible example an open a new issue?

kirill-linnik · 2022-10-29T13:59:01Z

I have the same problem with 22.0.4:
TS2322: Type 'DefaultTFuncReturn' is not assignable to type 'string | ReactElement<any, string | JSXElementConstructor<any>> | undefined'.
as a workaround, it looks like I should wrap all function invocation into <></>, which is a bit painful for a bit project. is there any other way fixing it?

Can you create a reproducible example an open a new issue?

hmm, now I'm a bit puzzled. it works nice in a sandbox:

but in my project (I even deleted yarn.lock and node_modules to have it "all fresh"), I get totally different definition of t:

"i18next": "22.0.4",
"i18next-browser-languagedetector": "7.0.0",
"react-i18next": "12.0.0",

I'm puzzled a bit. any idea why could it be the case?

kirill-linnik · 2022-10-29T15:14:46Z

ok, screw sandbox, I made a demo on top of playground project: #1574

pedrodurek · 2022-10-29T16:16:27Z

Hey @kirill-linnik, it seems message don't accept null, but t function could return null. I'd advice to fallback to something else. E.g.: t('key') ?? ''

badsyntax · 2022-11-05T06:28:05Z

I'm seeing something similar. As as temporary workaround I've been able to "fix" this by overriding the TFunction interface in my i18next.d.ts file, to apply the following change:

- TDefaultResult extends DefaultTFuncReturn = string,
+ TDefaultResult extends string = string,

In file `i18next.d.ts`:

import 'i18next';

declare module 'i18next' {
  interface TFunction<
    N extends Namespace = DefaultNamespace,
    TKPrefix = undefined
  > {
    <
      TKeys extends TFuncKey<N, TKPrefix> | TemplateStringsArray extends infer A
        ? A
        : never,
      TDefaultResult extends string = string,
      TInterpolationMap extends object = StringMap
    >(
      key: TKeys | TKeys[]
    ): TFuncReturn<N, TKeys, TDefaultResult, TKPrefix>;
    <
      TKeys extends TFuncKey<N, TKPrefix> | TemplateStringsArray extends infer A
        ? A
        : never,
      TDefaultResult extends stringWithObject = object,
      TInterpolationMap extends object = StringMap
    >(
      key: TKeys | TKeys[],
      options?: TOptions<TInterpolationMap> & {
        returnDetails: true;
        returnObjects: true;
      }
    ): TFunctionDetailedResult<TFuncReturn<N, TKeys, TDefaultResult, TKPrefix>>;
    <
      TKeys extends TFuncKey<N, TKPrefix> | TemplateStringsArray extends infer A
        ? A
        : never,
      TDefaultResult extends string = string,
      TInterpolationMap extends object = StringMap
    >(
      key: TKeys | TKeys[],
      options?: TOptions<TInterpolationMap> & { returnDetails: true }
    ): TFunctionDetailedResult<TFuncReturn<N, TKeys, TDefaultResult, TKPrefix>>;
    <
      TKeys extends TFuncKey<N, TKPrefix> | TemplateStringsArray extends infer A
        ? A
        : never,
      TDefaultResult extends stringWithObject = object,
      TInterpolationMap extends object = StringMap
    >(
      key: TKeys | TKeys[],
      options?: TOptions<TInterpolationMap> & { returnObjects: true }
    ): TFuncReturn<N, TKeys, TDefaultResult, TKPrefix>;
    <
      TKeys extends TFuncKey<N, TKPrefix> | TemplateStringsArray extends infer A
        ? A
        : never,
      TDefaultResult extends string = string,
      TInterpolationMap extends object = StringMap
    >(
      key: TKeys | TKeys[],
      options?: TOptions<TInterpolationMap>
    ): TFuncReturn<N, TKeys, TDefaultResult, TKPrefix>;
    <
      TKeys extends TFuncKey<N, TKPrefix> | TemplateStringsArray extends infer A
        ? A
        : never,
      TDefaultResult extends string = string,
      TInterpolationMap extends object = StringMap
    >(
      key: TKeys | TKeys[],
      defaultValue?: string,
      options?: TOptions<TInterpolationMap> | string
    ): TFuncReturn<N, TKeys, TDefaultResult, TKPrefix>;
  }
}

"i18next": "22.0.4",
"react-i18next": "12.0.0",

kirill-linnik · 2022-11-05T07:50:32Z

@badsyntax yeah, there are several ways to workaround it. I've decided to postpone the update until it is fixed properly

@pedrodurek seems like we need t to return string ;)

pedrodurek · 2022-11-07T19:41:03Z

If you have access to the translation files in build time and follow the instructions here, t function will always return the correct type (string).
Please take a look at our examples: https://github.com/i18next/react-i18next/tree/master/example/react-typescript, https://github.com/i18next/i18next/tree/master/examples/typescript

is-jonreeves · 2022-11-09T22:30:53Z

@pedrodurek we have also ran into this same issue while upgrading a few of our projects. For now I'm working around this with the following (based on the comment here):

types/react-i18next.d.ts

import 'react-i18next';

declare module 'i18next' {
  interface CustomTypeOptions {
    defaultNS: 'common';
    resources: {
      [key: string]: {
        [key: string]: string;
      };
    };
  }
}

We found that doing what the docs suggested and importing all of our namespace/JSON files resulted in a painfully slow VSCode. Further more, our projects use i18nHttpBackend to load the translations at runtime, so having to import/hardcode these into the project would unnecessarily bloat our resulting bundle and defeat the purposes of async loading the translations.

For what its worth I was able to import these into the d.ts file instead and I suspect it might not affect the bundle that way, however as I said the typechecking really slowed down.

import common from '@/../public/static/locales/en/common.json';
import home from '@/../public/static/locales/en/home.json';
...

declare module 'i18next' {
  interface CustomTypeOptions {
    defaultNS: 'common';
    resources: {
      common: typeof common;
      home: typeof home;
      ...
    };
  }
}

While the IDE prompts were nice (aside from the slowdown), I did run into a few other problems:

The DefaultNS doesn't appear to be taken into account and type errors appear, e.g...

// common.json
{
  "errors": {
    "unexpected": "Unexpected error"
  }
}

// home.json
{
  "page": {
    "title": "Welcome"
  }
}

// Relying on DefaultNS (common)
const { t } = useTranslation('home', { useSuspense: true });

console.log(✅, t('page.title'))
console.log(❌, t('common:errors.unexpected'))

// Explicitly including "common"
const { t } = useTranslation([ 'common', 'home' ], { useSuspense: true });

console.log(✅, t('home:page.title'))
console.log(✅, t('common:errors.unexpected'))

We weren't able to use dynamic strings any more:

console.log(✅, t('common:dates.days.mon'))
console.log(❌, t(`common:dates.days.${day}`))

With all of this in mind, and realizing my usecases may be the minority, it would still be great to see a way to bypass/disable the typing requirements as an option. For now the workaround mentioned above will work for me. Hope its helpful to others.

pedrodurek · 2022-11-11T01:08:02Z

Hey @is-jonreeves.

// Relying on DefaultNS (common)
const { t } = useTranslation('home', { useSuspense: true });

console.log(✅, t('page.title'))
console.log(❌, t('common:errors.unexpected'))

This pattern ☝️ is not supported due to compilation time constrains, I'd advice to explicitly include the "common" namespace. I'm working on some improvements that will allow us to do that, but it may require a lot of tests and benchmark.

console.log(✅, t('common:dates.days.mon'))
console.log(❌, t(`common:dates.days.${day}`))

day here needs to be a literal value, not only a string, otherwise it won't be type-safe. For example:

const day = 'today' as const;
// type inferred: 'today' instead of string

console.log(✅, t(`common:dates.days.${day}`))

with union type:

type Props = {
  day: 'today' | 'tomorrow' | 'yesterday'
}
const Component = ({day}: Props) => {
  console.log(✅, t(`common:dates.days.${day}`))
}

adrai · 2022-11-12T16:38:29Z

should be fixed with i18next v22.0.5

eiskalteschatten · 2022-11-13T17:18:05Z

v22.0.5 didn't fix it for me unfortunately. I am still getting the following error and had to downgrade to 22.0.3:

Type 'DefaultTFuncReturn' is not assignable to type 'string | undefined'.

I'm using the following with Node 18.12.1:

"i18next": "^22.0.5",
"react-i18next": "^12.0.0",
"typescript": "^4.8.4"

And if it helps, this is the project: https://github.com/eiskalteschatten/InOrdnung

manuelpoelzl · 2022-11-13T20:16:19Z

v22.0.5 didn't fix it for me unfortunately. I am still getting the following error and had to downgrade to 22.0.3:
Type 'DefaultTFuncReturn' is not assignable to type 'string | undefined'.
I'm using the following with Node 18.12.1:
"i18next": "^22.0.5",
"react-i18next": "^12.0.0",
"typescript": "^4.8.4"
And if it helps, this is the project: https://github.com/eiskalteschatten/InOrdnung

Have the exact same problem.

pedrodurek · 2022-11-14T23:25:48Z

t function can return null, this behaviour is set by default, if you want to change it, set returnNull type to false.

// i18next.d.ts
import 'i18next';

declare module 'i18next' {
  interface CustomTypeOptions {
    returnNull: false;
    ...
  }
}

I also recommend updating your i18next configuration to behave accordantly. https://www.i18next.com/overview/configuration-options#translation-defaults

i18next.init({
  returnNull: false,
   ...
});

schankam · 2022-11-15T09:15:07Z

t function can return null, this behaviour is set by default, if you want to change it, set returnNull type to false.
// i18next.d.ts
import 'i18next';

declare module 'i18next' {
  interface CustomTypeOptions {
    returnNull: false;
    ...
  }
}
I also recommend updating your i18next configuration to behave accordantly. https://www.i18next.com/overview/configuration-options#translation-defaults
i18next.init({
  returnNull: false,
   ...
});

Does not seem to work for me...

    "i18next": "^22.0.5",
    "i18next-browser-languagedetector": "^7.0.1",
    "i18next-http-backend": "^2.0.1",
    "react-i18next": "^12.0.0",

adrai · 2022-11-15T09:17:50Z

@schankam make sure you define returnNull: false in the init options and in the i18next.d.ts file...
if this still does not work, please provide a minimal reproducible example

Willham12 · 2022-11-21T17:20:33Z

in my case changing declare module 'react-i18next' --> declare module 'i18next' did the trick ;D

imransilvake · 2022-11-28T16:04:32Z

doesn't work

"i18next": "^22.0.6",
"react-i18next": "^12.0.0",

// init i18n
i18n.use(initReactI18next)
	.init({
		returnNull: false,
		resources: { en, de },
		lng: 'en',
		keySeparator: '.',
		interpolation: { escapeValue: false }
	})
	.then();

kazhuravlev · 2022-12-13T18:18:49Z

Until the problem not fixed, we can use some sort of crutch like:

function useXTranslation() {
  const {t} = useTranslation()

  return {t: t<string>};
}

and replace const { t } = useTranslation() to const { t } = useXTranslation()

my versions of i18next

...
 "i18next": "22.4.5",
 "react-i18next": "12.1.1",
...

NOTE: possibly this is insane advice. I am playing with TS/JS for only 5 days. But this is working for my case. 🤣

adrai · 2022-12-13T18:26:34Z

Until the problem not fixed, we can use some sort of crutch like:
function useXTranslate() {

  const {t} = useTranslation()



  return {t: t<string>};

}
and replace const { t } = useTranslate() to const { t } = useXTranslate()

my versions of i18next
...

 "i18next": "22.4.5",

 "react-i18next": "12.1.1",

...
NOTE: possibly this is insane advice. I am playing with TS/JS for only 5 days. But this is working for my case. 🤣

Have you tried with i18next v22.4.5 ?

kazhuravlev · 2022-12-13T18:36:55Z

@adrai I think yes, because my version is 22.4.5. May this output will be more helpful:

$ npm ll | grep i18next                                                                                                                                                   
├── i18next-browser-languagedetector@7.0.1
├── i18next@22.4.5
├── react-i18next@12.1.1

This is looks like I use exactly 22.4.5

adrai · 2022-12-13T18:42:21Z

a minimal reproducible example repository would help

kazhuravlev · 2022-12-13T18:56:43Z

@adrai https://github.com/kazhuravlev/i18next-is-broke-by-project/blob/master/src/App.tsx#L9

kazhuravlev · 2022-12-13T19:00:10Z

Almost all people in this thread is describe the same problem with type definitions. No new info in my case.

If you need an additional info - feel free to ask.

adrai · 2022-12-13T19:09:16Z

Almost all people in this thread is describe the same problem with type definitions. No new info in my case.

If you need an additional info - feel free to ask.

I don't see any i18next.d.ts file defining returnNull: false;: https://www.i18next.com/overview/typescript#argument-of-type-defaulttfuncreturn-is-not-assignable-to-parameter-of-type-xyz

kazhuravlev · 2022-12-13T19:20:47Z

wow. this is working. thx.

But also, I think that this functional should be working without additional manipulations around the code. Hope we will get a function that will return just a strings.

adrai · 2022-12-13T19:32:20Z

Like described, the t function is potentially returning null... but it might be in the next major version we will set the default for returnNull to false => i18next/i18next#1884

m-nathani · 2022-12-19T09:45:25Z

Like described, the t function is potentially returning null... but it might be in the next major version we will set the default for returnNull to false => i18next/i18next#1884

any expected date on when it could be released ? otherwise we can keep using the old version 22.0.6 ,

adrai · 2022-12-19T09:48:55Z

@m-nathani no ETA at the moment... waiting for @pedrodurek's feedback...
in the meantime set returnNull to false yourself https://www.i18next.com/overview/typescript#argument-of-type-defaulttfuncreturn-is-not-assignable-to-parameter-of-type-xyz

m-nathani · 2022-12-19T11:33:07Z

@m-nathani no ETA at the moment... waiting for @pedrodurek's feedback...
in the meantime set returnNull to false yourself https://www.i18next.com/overview/typescript#argument-of-type-defaulttfuncreturn-is-not-assignable-to-parameter-of-type-xyz

Sounds great.. thanks for the link 👍

adrai assigned pedrodurek Oct 7, 2022

adrai added the typescript label Oct 7, 2022

stale bot added the stale label Oct 15, 2022

stale bot removed the stale label Oct 20, 2022

adrai mentioned this issue Oct 20, 2022

Add documentation for the new breaking change in TS i18next/i18next#1852

Closed

pedrodurek mentioned this issue Oct 27, 2022

Omit object from t function i18next/i18next#1858

Merged

7 tasks

pedrodurek mentioned this issue Nov 11, 2022

Change DefaultTFuncReturn to return null if returnNull typeOption is true i18next/i18next#1865

Merged

7 tasks

adrai closed this as completed in i18next/i18next#1865 Nov 12, 2022

adrai mentioned this issue Nov 16, 2022

Translation function return type DefaultTFuncReturn makes React Native errors i18next/i18next#1868

Closed

adrai mentioned this issue Dec 13, 2022

Consider setting the default for returnNull to false in next major version (v23.0.0) i18next/i18next#1884

Closed

14 tasks

ChelseaKR mentioned this issue Dec 17, 2022

chore(deps): bump react-i18next from 11.18.6 to 12.1.1 in /frontend newjersey/dol-mcnj-main#670

Merged

withTranslation - Type error: Type 'TFunctionResult' is not assignable to type 'ReactNode' #1559

withTranslation - Type error: Type 'TFunctionResult' is not assignable to type 'ReactNode' #1559

Comments

MarcelGeo commented Oct 7, 2022

stale bot commented Oct 15, 2022

manwaring commented Oct 20, 2022

denizguzel commented Oct 20, 2022

adrai commented Oct 20, 2022

meyfa commented Oct 20, 2022

SergioTx commented Oct 21, 2022 • edited

meyfa commented Oct 21, 2022

florianbepunkt commented Oct 26, 2022

adrai commented Oct 26, 2022

chybisov commented Oct 26, 2022

adrai commented Oct 27, 2022

karesztrk commented Oct 27, 2022

adrai commented Oct 27, 2022 • edited

kirill-linnik commented Oct 29, 2022

adrai commented Oct 29, 2022

kirill-linnik commented Oct 29, 2022 • edited

kirill-linnik commented Oct 29, 2022

pedrodurek commented Oct 29, 2022

badsyntax commented Nov 5, 2022 • edited

kirill-linnik commented Nov 5, 2022

pedrodurek commented Nov 7, 2022

is-jonreeves commented Nov 9, 2022

pedrodurek commented Nov 11, 2022 • edited

adrai commented Nov 12, 2022

eiskalteschatten commented Nov 13, 2022 • edited

manuelpoelzl commented Nov 13, 2022

pedrodurek commented Nov 14, 2022

schankam commented Nov 15, 2022

adrai commented Nov 15, 2022

Willham12 commented Nov 21, 2022

imransilvake commented Nov 28, 2022 • edited

kazhuravlev commented Dec 13, 2022 • edited

adrai commented Dec 13, 2022

kazhuravlev commented Dec 13, 2022

adrai commented Dec 13, 2022

kazhuravlev commented Dec 13, 2022

kazhuravlev commented Dec 13, 2022

adrai commented Dec 13, 2022

kazhuravlev commented Dec 13, 2022

adrai commented Dec 13, 2022

m-nathani commented Dec 19, 2022

adrai commented Dec 19, 2022

m-nathani commented Dec 19, 2022

SergioTx commented Oct 21, 2022 •

edited

adrai commented Oct 27, 2022 •

edited

kirill-linnik commented Oct 29, 2022 •

edited

badsyntax commented Nov 5, 2022 •

edited

pedrodurek commented Nov 11, 2022 •

edited

eiskalteschatten commented Nov 13, 2022 •

edited

imransilvake commented Nov 28, 2022 •

edited

kazhuravlev commented Dec 13, 2022 •

edited