feat!: Inherit context in case nested NextIntlClientProvider instances are present

[amannn]

If you have nested providers, previously only the configuration of the innermost one would be applied.

With this change, configuration is now passed from one provider to the next, while allowing to override individual props. This simplifies the configuration of onError and getMessageFallback if you're using those (see proposed docs).

Breaking change: There's a very rare chance that this change affects your app, but in case you've previously relied on providers not inheriting from each other, you now have to reset props manually in case you want to retain the previous behavior.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
next-intl-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Oct 9, 2024 5:36pm
next-intl-example-app-router	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Oct 9, 2024 5:36pm
next-intl-example-app-router-without-i18n-routing	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Oct 9, 2024 5:36pm

[amannn]

Doesn't minify terribly well, but can't really think of a better solution …

[dmitrc]

@amannn, thanks for your great work as always!

I was wondering if it also makes sense to optionally allow the user to merge the existing and current messages as well, eg to support the nested providers where you provide essential client messages in the root layout, and then component-specific messages later down the tree?

[amannn]

@dmitrc Thank you for the kind words and happy new year!

Merging such messages is certainly an interesting use case, yes. Currently, you could achieve this manually in userland.

Ideally, with #1, relevant messages for Client Components would be picked automatically—not requiring the developer to think in terms of "essential" client messages and "component-specific" ones.

#1 and #962 are the two main features I'd like to explore next for next-intl. If this works out well, I think we might not have to add merging of messages to next-intl. Due to this, I think for the time being I'd not add this behavior to next-intl.

Does that sound right to you?

[dmitrc]

Due to this, I think for the time being I'd not add this behavior to next-intl.
Does that sound right to you?

Yup, this makes complete sense, and I am incredibly excited about the improvements that solving #1 would bring!

The only challenge in implementing it in userland is that it requires some opinionated setup:

• We can't obtain the whole IntlContext as it is not exposed, so we have to do it piecewise
• We can obtain the messages via useMessages to merge them, but the hook will throw if it hasn't been set earlier
• Since wrapping hooks in try/catch is a no-no, we have to ensure to set <NextIntlClientProvider messages={{}}> at the root
• Subsequently our own <NestedNextIntlClientProvider ...> can be used to merge the new messages with prior ones

Not too big of a deal, but the second bullet caught me by surprise a little :)