Export `Locale` types to create custom `Locale` interface about next-international HOT 7 CLOSED

Also, this would remove the need for some methods in createI18n that were used only to get the right type, resulting in better code-splitting.

from next-international.

I understand better the issue. We can definitely export those two types and add an example in the README on how to set up an explicit interface for locales.

from next-international.

Landed in version 0.0.5 (#10), thanks!

from next-international.

I like this idea. It can be taken even further by overriding an interface declared in next-international, to avoid the generic on createI18n, and import defineLocale directly from the package:

// locales/index.ts
import { createI18n } from 'next-international';

declare module 'next-international' {
  interface Locale {
    hello: string
  }
}

export const {
  useI18n,
  // ...
} = createI18n({
  en: () => import('./en'),
});

// locales/en.ts
import { defineLocale } from 'next-international';

export default defineLocale({
  hello: 'Hello',
})

The downside is that you must duplicate all your keys to define them in the type (MyCustomLocale in your example), instead of writing them only in the locale files.

But it should also work with JSON locales, so maybe we can explicitly type the parameters to get type-safety while using JSON files:

// locales/en.json
{
  "hello": "Hello {param}, this is {anotherParam}"
}

// locales/index.ts
interface Locale {
  hello: '{param} {anotherParam}';
}

const { useI18n } = createI18n({
  en: () => import('./en.json'),
});

const { t } = useI18n()
// can have type-safety
t('hello', {
  param: '',
  anotherParam: '',
})

from next-international.

After trying a bit more moving in this direction, I'm not sure if it's a good idea:

• One of the goals of this lib is to avoid explicitly creating the types for the locales, which will not be the case if we move in this direction
• Adding a new key in locales should be as simple as adding it to the locales files - here, we would need to also add it to the interface in order to use it

Let me know what you think.

from next-international.

These are fair points. However I currently feel like offering the option to create an explicit locale interface would still be good.
The primary reason I am in favour of offering it as an option is this:

Adding a new key in locales should be as simple as adding it to the locales files

For example, if a new hire or community member wants to contribute to a OS project & they have not used next-international before they may not understand that in order to change or update the locale schema they will need to update the "default locale", or whatever one is used for type inference, first in order for the type inference to be updated & other locales to require the new locales.

Some people may like the current method, and that is fine, but I personally find it odd to need to update the data structure of one file to change others & think it would be better to offer explicit types as an option.

Currently there is a simple way around this by just redefining the LocaleValue & Locale types:

type LocaleValue = string | number;

type BaseLocale = Record<string, LocaleValue>;

While this works it would be better if these were exported by the package to be consumed in case of any changes during dependency upgrades.

from next-international.

Created #10, feel free to check the PR and leave me your feedback.

from next-international.