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

☂️ Umbrella: List of potential features / changes for a major version #779

Open
9 tasks
amannn opened this issue Jan 16, 2024 · 4 comments
Open
9 tasks
Labels
enhancement New feature or request

Comments

@amannn
Copy link
Owner

amannn commented Jan 16, 2024

This is a list of ideas for API changes that we could potentially introduce in a major version:

  • Improve initial render of Link for localePrefix: 'as-necessary' and make getPathname more useful #444
  • Maybe we could automatically forward formats to Client Components with an option to opt-out (formats={null}). Keep in mind: fix: Don't retrieve defaults for locale, now and timeZone if these options have been provided to NextIntlClientProvider #633. See previously proposed docs changes in 80332fc.
  • Return typed messages from useMessages? Consider that only a subset of the existing messages might be returned though.
  • Add IntlFormats for strict typing of formats
  • It's strongly encouraged to render NextIntlClientProvider from a Server Component, as we can automatically inherit config there. Do we need better error handling if the user renders this component from a Client Component? There are still valid use cases for this, e.g. for unit testing / Storybook.
  • Add validation in plugin that no trailing slashes config is supported
  • Add an API to define routing config in central place (e.g. defineRouting)?
  • Replace createSharedPathnamesNavigation and createLocalizedPathnamesNavigation with a single factory function? Support for pathnames only accounts for 0.28 kB and we could provide an easier getting started experience by only offering one. We need to check if overloading for both use cases works as expected though.
  • Use /${string} for stricter typing of pathnames instead of string

No decision has been made on these so far, but if you have feedback about these points, please leave it here!

@amannn amannn added enhancement New feature or request unconfirmed Needs triage. labels Jan 16, 2024
@amannn amannn changed the title Considerations for [email protected] Potential API changes Jan 16, 2024
@amannn
Copy link
Owner Author

amannn commented Jan 17, 2024

Adding the prefix for getPathname was also discussed in #785 (reply in thread).

@amannn amannn changed the title Potential API changes List of potential features / changes for a major version Jan 19, 2024
@amannn amannn removed the unconfirmed Needs triage. label Feb 6, 2024
@amannn amannn changed the title List of potential features / changes for a major version ☂️ Umbrella: List of potential features / changes for a major version Mar 28, 2024
@vricop
Copy link

vricop commented May 7, 2024

Return typed messages from useMessages would be really nice.

Does anyone know a workaround for this?

@vricop
Copy link

vricop commented May 8, 2024

Return typed messages from useMessages would be really nice.

Does anyone know a workaround for this?

I find out how to properly type safe the useMessages hook temporarily.

We can overload the function in our ./global.d.ts types like this:

import en from 'messages/en.json'

export type Messages = typeof en

declare module 'next-intl' {
  interface IntlMessages extends Messages {}
  
  function useMessages(): IntlMessages;
}

image

@vricop
Copy link

vricop commented May 8, 2024

Return typed messages from useMessages would be really nice.
Does anyone know a workaround for this?

I find out how to properly type safe the useMessages hook temporarily.

We can overload the function in our ./global.d.ts types like this:

import en from 'messages/en.json'

export type Messages = typeof en

declare module 'next-intl' {
  interface IntlMessages extends Messages {}
  
  function useMessages(): IntlMessages;
}

image

⚠️🚨 DON'T DO THIS. I FIND OUT IT BREAKS t() TYPE SAFETY ⚠️🚨

After trying many things I ended using type assertion with as:

 const t = useTranslations()
 const message = useMessages() as unknown as Messages

Not ideal, but at least there's a workaround.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants