Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using context with Typescript doesn't seem to resolve types properly #1617

Closed
litera opened this issue Feb 21, 2023 · 10 comments
Closed

Using context with Typescript doesn't seem to resolve types properly #1617

litera opened this issue Feb 21, 2023 · 10 comments
Assignees

Comments

@litera
Copy link

litera commented Feb 21, 2023

馃悰 Bug Report

I'm getting typescript error when I use context with my translations.

To Reproduce

A minimal reproducible example.
The interesting thing is that the code runs correctly (at least in the example Stackblitz). In the code there's a typescript error same as in my project.

Expected behaviour

I've defined i18next.d.ts as instructed by the docs, initialized the i18next but I can't seem to make the context work as per documentation. Or at least the documentation is missing more information about Typescript usage.

Your Environment

  • i18next version: latest
  • react-i18next version: latest
  • typescript version: latest
@litera
Copy link
Author

litera commented Feb 21, 2023

If I also add the defaultValue property, the error gets away. But adding the prop should not be mandatory when one uses context. So until this Typescript bug is resolved, I'll provide the defaultValue to my context translation usages to mitigate around the problem (of course not a solution, but may help others).

@litera litera changed the title using context with Typescript doesn't seem to resolve types properly Using context with Typescript doesn't seem to resolve types properly Feb 22, 2023
@stale
Copy link

stale bot commented Mar 18, 2023

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.

@stale stale bot added the stale label Mar 18, 2023
@adrai adrai removed the stale label Mar 18, 2023
@stale
Copy link

stale bot commented Apr 3, 2023

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.

@stale stale bot added the stale label Apr 3, 2023
@adrai adrai removed the stale label Apr 3, 2023
@stale
Copy link

stale bot commented Apr 26, 2023

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.

@stale stale bot added the stale label Apr 26, 2023
@adrai adrai removed the stale label Apr 26, 2023
@stale
Copy link

stale bot commented May 8, 2023

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.

@stale stale bot added the stale label May 8, 2023
@adrai adrai removed the stale label May 24, 2023
@stale
Copy link

stale bot commented Jun 10, 2023

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.

@stale stale bot added the stale label Jun 10, 2023
@adrai adrai removed the stale label Jun 10, 2023
adrai added a commit to i18next/i18next that referenced this issue Jun 13, 2023
@adrai
Copy link
Member

adrai commented Jun 13, 2023

#1541

@adrai
Copy link
Member

adrai commented Jul 29, 2023

@adrai adrai closed this as completed Jul 29, 2023
@Jelle-vz
Copy link

Jelle-vz commented Mar 7, 2024

Was this resolved actually? I still get the same error:

Code
t('COMMON:DEVICES.STATUS', { context: hardwareInfo.devices.DOCUMENT_SCANNER ? 'ENABLED' : 'DISABLED' })

throws:
Argument of type '["COMMON:DEVICES.STATUS", { context: "ENABLED" | "DISABLED"; }]' is not assignable to parameter of type '[key: TemplateStringsArray | TemplateStringsArray[], options?: { readonly context: "ENABLED" | "DISABLED"; }] | [key: string | string[], options: { readonly context: "ENABLED" | "DISABLED"; } & $Dictionary & { ...; }] | [key: ...]'. Type '["COMMON:DEVICES.STATUS", { context: "ENABLED" | "DISABLED"; }]' is not assignable to type '[key: string | string[], defaultValue: string, options?: { readonly context: "ENABLED" | "DISABLED"; } & $Dictionary]'. Type at position 1 in source is not compatible with type at position 1 in target. Type '{ context: "ENABLED" | "DISABLED"; }' is not assignable to type 'string'.ts(2345)

working with:
"i18next": "^23.10.0", "react-i18next": "^14.0.5",

@adrai
Copy link
Member

adrai commented Mar 7, 2024

Was this resolved actually? I still get the same error:

Code t('COMMON:DEVICES.STATUS', { context: hardwareInfo.devices.DOCUMENT_SCANNER ? 'ENABLED' : 'DISABLED' })

throws: Argument of type '["COMMON:DEVICES.STATUS", { context: "ENABLED" | "DISABLED"; }]' is not assignable to parameter of type '[key: TemplateStringsArray | TemplateStringsArray[], options?: { readonly context: "ENABLED" | "DISABLED"; }] | [key: string | string[], options: { readonly context: "ENABLED" | "DISABLED"; } & $Dictionary & { ...; }] | [key: ...]'. Type '["COMMON:DEVICES.STATUS", { context: "ENABLED" | "DISABLED"; }]' is not assignable to type '[key: string | string[], defaultValue: string, options?: { readonly context: "ENABLED" | "DISABLED"; } & $Dictionary]'. Type at position 1 in source is not compatible with type at position 1 in target. Type '{ context: "ENABLED" | "DISABLED"; }' is not assignable to type 'string'.ts(2345)

working with: "i18next": "^23.10.0", "react-i18next": "^14.0.5",

please provide a minimal reproducible example, not just code snippets... in case you can reproduce this, please open a new issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants