Question: Multiple 'useTranslations' calls in the same component about next-intl

[amannn]

Hi @arunmenon1975,

nice to hear from you and thank you for considering next-intl for your app 🙂 .

Having multiple useTranslations hook calls in the same component is perfectly fine from a performance perspective.

In the guide, there's a section about how I recommend to structure messages. Personally I'm in favour of scoping messages to a component, but you can of course do what suits you best.

I guess if you cross reference messages from different namespaces, the issue is mostly that you have to get a bit creative with how you call your returned translation function. As mentioned in the guide, you can however also retrieve all available messages in your component and use full paths at the individual call sites. That way you only have a single hook call and a single translation function.

Does this help?

[amannn]

Sounds good!

Yep, I agree. For really large apps I think the automatically generated IDs from react-intl and also message descriptions can be useful – I made a note about this in the FAQ.

At least for the apps I've worked on so far, which tend to be more on the small to medium size as well, I was happy so far we've the tradeoffs of next-intl.

[arunmenon1975]

Ok and yes, definitely helps. Thanks for the response and the suggestions. The main reason for these very basic questions was because i saw #15 that talked about re-renders of the t and thought ill double check before really starting out making changes. My app is not overly componentized at the moment so i did foresee requiring multiple instances to be defined.

I had gone ahead in the meanwhile and started with the implementation and so far everything has been good. The library has it all - including the possibility of potentially having the messages reside remotely(i will definitely be exploring this at a later point since my app has certain admin capabilities and allowing for even the core strings to be configurable without requiring builds is definitely very useful), something that not many of the other major 1i8n libraries support without major trade-offs in a nextjs implementation.

The only (inescapable) issue - well, not exactly an issue but more of a Dx related enhancement opportunity - is that i would need to have a well-defined structure in place or risk getting confused with all the names and structure that needs definition. Will need clear forethought about structure and not as easy as say <FormattedMessage defaultMessage="My message" />. Or alternatively, it would be great if i could somehow get my defined namespaces via intellisense through somehow having them type-defined and avoid, at a minimum, the potential for typos. At the moment however i am stretching my 'naming' skills to the max and it seems ok.

Since only relevant translations are loaded per page, some overlap/duplication of the strings are ok and things balance out from an ease-vs-optimal viewpoint.

Thanks for your suggestions - i will be trying them out. I have finalized next-intl for my project since it has all what i am looking for.

[amannn]

Nice, thanks for the feedback!

Will need clear forethought about structure and not as easy as say

Yep, that's true. next-intl has the API decision that labels are always defined outside of code and therefore you need some kind of mapping via identifiers.

Or alternatively, it would be great if i could somehow get my defined namespaces via intellisense through somehow having them type-defined and avoid, at a minimum, the potential for typos.

That's true, I'd definitely also like that. I'm not sure what the best approach to handle this is though. E.g. if you want to load translations from a remote sever, we can't really infer the shape.

For local messages it might be easier, but also here are some considerations. Either you'd have to pass a type to every useTranslations call site, or there would be a factory function which would create the provider & the hooks and restrict them with type information. You'd have to import from those created instances then instead of the library – also not ideal.

Not sure, really … For now I focused on helpful error messages. If you have some kind of testing infrastructure that throws when there are console errors, you might get the same safety. However auto-complete would still be handy.

[arunmenon1975]

ok. And since there is support for nested messages as well and not as clear cut as simply flattened objects i guess, like you said, it will be difficult to get a one-size-fits-all sort of solution going.

For now I focused on helpful error messages. If you have some kind of testing infrastructure that throws when there are console errors, you might get the same safety

The console errors are very useful indeed. Since i am at an early stage of planning the structure of the messages, i keep getting a bunch of it in my console - mostly typos and trailing commas related - and it does point to the exact property name so i don't have to search for them. Per the docs, I also see that this is optionally configurable as well.

I am happy as things are though. My app currently is more on the small-to-medium end of the size scale and definitely easily manageable. I think apps thats may have 100s of 1000s of strings may need a more focussed look at structure and how to handle the namespacing optimally, which i think is beyond the scope of the library anyway. The documentation of suggestions is quite useful here.