feat(typings): support readonly namespaces in TFuncKey

[belgattitude]

Follow up of

• feat(types): allow readonly namespaces in useTranslation, see feat(types): allow readonly namespaces in useTranslation #1339

While the initial P/R allows to readonly namespace array... the t function choose to fallback to all configured namespaces (ie: 'common', 'home', 'other-context')... defeating perfect typechecks

export const nsPageConfig = ['common', 'home'] as const; 
export const Page = () => {
  // 1. Ok it works thx https://github.com/i18next/react-i18next/pull/1339
  const { t } = useTranslation(nsPageConfig);
  return (
    <div>
       // 2. Ok it works, the typecheck occurs 
       <span>{t('home:thekeyexists')}</span>
       // 3. Oups, it allows 'other-context', but it's not in the nsPageconfig
       <span>{t('other-context:thekeyexists')}</span>
    </div>
  );
}

With this P/R it will work well.

But, I'd like to have a second reading on this... cause in my guts I feel that changing the signature of TFuncKey would see a theoretical drop of performance...

I need to check it out on a larger project or maybe a typescript guru would find a better way ?

An option that I'm investigating also is to remove readonly from useTranslation return, I don't know how to it... Something in the lines of

export function useTranslation<N extends Namespace = DefaultNamespace>(
  ns?: N | Readonly<N>,
  options?: UseTranslationOptions,
  // Here trying out to remove the readonly modifier on the array
  // That would allow to not change the TFuncKey signature
): UseTranslationResponse<MAKEMUTABLEIFREADONLY<N>>;

Checklist

• only relevant code is changed (make a diff before you submit the PR)
• run tests npm run test
• tests are included
• documentation is changed or added

[coveralls]

Coverage remained the same at 96.583% when pulling b8d65b0 on belgattitude:typings-allow-const-tfunckey into 4f5ee74 on i18next:master.

[belgattitude]

@adrai are you the ts guru ? 😄

The reason why I'm trying to have a config object is to reuse it in an hybrid app (nextjs)... so my both my ssr and client page share the same namespace config... It's just a detail and I can really live without.

[adrai]

No, it's @pedrodurek 😉

[belgattitude]

Tried with no luck to find a better option than changing the TFuncKey, and do it in the useTranslation return but still no luck

In the meantime, we can deal with this in the code as the slice() on a ReadonlyArray removes the readonly constraint...

i.e:

export const nsPageConfig = ['common', 'home'] as const; 
export const Page = () => {
  const { t } = useTranslation(
      // Calling slice here will remove the readonly constraint and
      // so we're fine somehow
      nsPageConfig.slice()
  );
  return (
    <div>
       // 2. Ok it works, the typecheck occurs 
       <span>{t('home:thekeyexists')}</span>
       // 3. OK now it correctly complain cause other-context is not in nsPageConfig
       <span>{t('other-context:thekeyexists')}</span>
    </div>
  );
}

Update

A little check in ast is present here

[stale]

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.

[pedrodurek]

Looks great, thanks @belgattitude!

[adrai]

patch or minor?

[pedrodurek]

patch

[adrai]

released with v11.11.2