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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strict typing of global formats #1112

Open
amannn opened this issue Jun 7, 2024 · 3 comments · May be fixed by #1346
Open

Strict typing of global formats #1112

amannn opened this issue Jun 7, 2024 · 3 comments · May be fixed by #1346
Labels
area: ergonomics contributions welcome Good for people looking to contribute enhancement New feature or request

Comments

@amannn
Copy link
Owner

amannn commented Jun 7, 2024

Is your feature request related to a problem? Please describe.

Similar to how we support strict typing of messages, we could provide strict typing for formats.

Describe the solution you'd like

Allow the user to define IntlFormats to enable this.

Describe alternatives you've considered

Not providing strict formats.

@amannn amannn added enhancement New feature or request unconfirmed Needs triage. and removed unconfirmed Needs triage. labels Jun 7, 2024
@amannn amannn added the contributions welcome Good for people looking to contribute label Sep 17, 2024
@dBianchii
Copy link

dBianchii commented Sep 17, 2024

Hey, I think I might be interested in implementing this. I was thinking of setting it close to their type definition for messages, like:

import en from './messages/en.json'
import formats from '~/i18/request.ts'
 
type Messages = typeof en;
 
declare global {
  // Use type safe message keys with `next-intl`
  interface IntlMessages extends Messages {}
type IntlFormats = typeof formats

}

Something quite like that. Do you think that this api could work? Then the user would only need to do this once and any changes to their format object would reflect the type here

@amannn
Copy link
Owner Author

amannn commented Sep 17, 2024

If you're up for it, that would be 💯!

As far as I know, it has to be an interface in order to work. Interfaces have this special ability in TypeScript that declarations can be merged when re-declared.

Based on the implementation for the messages, I think these are the required steps:

  1. Add a local type in use-intl/types that will be used for type checking within this repo:
    // This type is intended to be overridden
    // by the consumer for optional type safety
    declare interface IntlMessages extends Record<string, any> {}
  2. Use the type were relevant:

Now, when a consumer installs the package, the IntlMessages type is not available, therefore defaulting to any. As soon as the consumer declares the type on the global namespace, this type will be picked up where relevant.

Maybe with a condition we could still ensure that only a string is accepted for a local format in case no IntlFormats are provided? That would probably be something to be researched. EDIT: Out-of-the-box, we support the date formats full, long, medium and short—maybe we could consider that as a default (including & {} to allow user-specified strings)? For number formatting there are defaults for currency and percent.

Let me know in case I can help with something! 🙌

@dBianchii
Copy link

If you're up for it, that would be 💯!

As far as I know, it has to be an interface in order to work. Interfaces have this special ability in TypeScript that declarations can be merged when re-declared.

Based on the implementation for the messages, I think these are the required steps:

  1. Add a local type in use-intl/types that will be used for type checking within this repo:
    // This type is intended to be overridden
    // by the consumer for optional type safety
    declare interface IntlMessages extends Record<string, any> {}
  2. Use the type were relevant:

Now, when a consumer installs the package, the IntlMessages type is not available, therefore defaulting to any. As soon as the consumer declares the type on the global namespace, this type will be picked up where relevant.

Maybe with a condition we could still ensure that only a string is accepted for a local format in case no IntlFormats are provided? That would probably be something to be researched. EDIT: Out-of-the-box, we support the date formats full, long, medium and short—maybe we could consider that as a default (including & {} to allow user-specified strings)? For number formatting there are defaults for currency and percent.

Let me know in case I can help with something! 🙌

Thanks. Will look into it when I have some free time.

@dBianchii dBianchii linked a pull request Sep 18, 2024 that will close this issue
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: ergonomics contributions welcome Good for people looking to contribute enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants