Expose serializable useFormats

[jd-carroll]

Is your feature request related to a problem? Please describe.

When using the NextIntlClientProvider there is current no way (that I saw) to access the formats in the same you are able to access the the "messages". The only available option is useFormatter which returns a function. However if you are trying to use NextIntlClientProvider you cannot serialize the function and pass it to the provider.

Describe the solution you'd like

In addition to useFormatter it would be great if there was a parallel to useMessages, such as useFormats, which returns a serializable form of the formts.

Describe alternatives you've considered

I don't think there are any alternatives

[amannn]

Can you elaborate on what the use case is? Is the issue that formats aren't automatically available on the client side? I'm currently considering changing this, making formats that are defined in i18n.ts automatically available on the client side (with an opt-out mechanism, if necessary)—see #779.

On a side note, the alternative is exporting your formats from a module and importing it in all relevant places.

Would be curious to learn more about your use case!

[jd-carroll]

Correct, that formats is not available on the client side. And agreed, there are any number of ways I can do this (which I am), but was just trying to keep things consistent.

As for the app, it is a password manager of sorts, so very client centric since we do not have access to the data rendered. (Maybe we could do more server rendering, but not sure I've completely wrapped my head around how that would work so skipping for now)

We are also exporting (output: 'export') the NextJS app to use with Tauri.

[amannn]

Thanks for including some context! Since this behavior might be changed in the future and formats would be automatically available on the client side, I think I wouldn't introduce a new API at this point—also given that a reasonable alternative is available. I hope you can understand!

Once something is public API, we have to maintain it or carefully deprecate it once necessary and I think in this case it's currently not worth it. Sorry for pushing a bit back here, I really appreciate that you immediately went ahead and have set up a PR!

[jd-carroll]

All good, if I don’t submit a PR I don’t learn as much… But I’ll ask, do you think I’m opting in to the Provider too quickly?

…

On Mon, Apr 8, 2024 at 10:54 PM Jan Amann ***@***.***> wrote: Thanks for including some context! Since this behavior might be changed in the future and formats would be automatically available on the client side, I think I wouldn't introduce a new API at this point—also given that a reasonable alternative is available. I hope you can understand! Once something is public API, we have to maintain it or carefully deprecate it once necessary and I think in this case it's currently not worth it. Sorry for pushing a bit back here, I really appreciate that you immediately went ahead and have set up a PR! — Reply to this email directly, view it on GitHub <#981 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOMNKDH7B4Y5TNLCX5F4FLY4N7AZAVCNFSM6AAAAABFZRLRJWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBUGE4TSMBRGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[amannn]

It depends a bit on your app. For some apps more on the "website" end of the spectrum, you can get very far with Server Components, while for more interactive experiences, usage of the provider is necessary.

I'm planning to improve the capabilities of next-intl for working with apps that are more in the middle of the spectrum:

1. Automatic tree-shaking of messages #1
2. Ahead-of-time compilation of messages #962

If this goes well, it should feel less like a "am I doing the right thing" when stepping to the client side, but something that is naturally supported without tradeoffs.

Hope this helps!

I'll close this issue since the original issue seems to be have been answered.