Open amannn opened 7 months ago
Adding the prefix for getPathname
was also discussed in https://github.com/amannn/next-intl/discussions/785#discussioncomment-8159571.
Return typed messages from useMessages
would be really nice.
Does anyone know a workaround for this?
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;
}
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; }
⚠️🚨 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.
The big goal for the next major release is to get everything out of the way that a) makes the setup harder than necessary and b) could slow down feature development for the foreseeable future.
Features that we can already introduce in 2.x in a backwards-compatible way:
This is a list of ideas for API changes that we could potentially introduce in a major version:
formats
to Client Components with an option to opt-out (formats={null}
). Keep in mind: https://github.com/amannn/next-intl/pull/633. See previously proposed docs changes in https://github.com/amannn/next-intl/pull/1046/commits/80332fc2a2daf66ea271617deb5abd2b3b10e46e.localePrefix: 'always'
case though (and only if the user doesn't want to automatically redirect/users
→/en/users
). Is this helpful?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 though, e.g. for unit testing / Storybook and in the Pages Router.DomainsConfig[number]['locales']
so that a domain only supports thedefaultLocale
by default, but other domains can be explicitly added? This might make the common case easier. If we do this, we could provide alternate links OOTB. But we need to include runtime error handling if not all locales are handled by a separate domain.next.config.js
might be the trickiest one, but Node.js 22 (scheduled to be recommended by Autumn '24) supportsrequire
ing ESM from CJS too. Alternatively we could consider making an exception fornext-intl/plugin
.@babel/preset-env
, as "safari 12" results in rest params being compiled. In exchange, we can reduce bundle size. Does Next.js apply code transforms for backwards compat anyway tonode_modules
?next-intl
, butuse-intl
works (see https://github.com/amannn/next-intl/issues/1282, also the comment inNextIntlClientProvider.tsx
)No decision has been made on these so far, but if you have feedback about these points, please leave it here!