-
-
Notifications
You must be signed in to change notification settings - Fork 184
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
Comments
Adding the prefix for |
Return typed messages from Does anyone know a workaround for this? |
I find out how to properly type safe the We can overload the function in our import en from 'messages/en.json'
export type Messages = typeof en
declare module 'next-intl' {
interface IntlMessages extends Messages {}
function useMessages(): IntlMessages;
} |
After trying many things I ended using type assertion with const t = useTranslations()
const message = useMessages() as unknown as Messages Not ideal, but at least there's a workaround. |
This is a list of ideas for API changes that we could potentially introduce in a major version:
Link
forlocalePrefix: 'as-necessary'
and makegetPathname
more useful #444formats
to Client Components with an option to opt-out (formats={null}
). Keep in mind: fix: Don't retrieve defaults forlocale
,now
andtimeZone
if these options have been provided toNextIntlClientProvider
#633. See previously proposed docs changes in 80332fc.useMessages
? Consider that only a subset of the existing messages might be returned though.IntlFormats
for strict typing offormats
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.defineRouting
)?createSharedPathnamesNavigation
andcreateLocalizedPathnamesNavigation
with a single factory function? Support forpathnames
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./${string}
for stricter typing of pathnames instead ofstring
No decision has been made on these so far, but if you have feedback about these points, please leave it here!
The text was updated successfully, but these errors were encountered: