Next-i18next: Migrate to react-i18next v10

[isaachinman]

As per discussion in #162, we'll need to make core/breaking changes (internally) to upgrade to react-i18next v10. The end-user API should remain the same (as react-i18next, anyways).

[lucasfeliciano]

Future reference: https://github.com/isaachinman/next-i18next/pull/162#issuecomment-460996531

[beheh]

An issue I'm facing with v10 is that the new react-i18next hook (useTranslation) invokes React's new Suspense API whilst waiting on the (i18next) backend. This is not supported yet on the server renderer which leads to it crashing with the "Invariant Violation: ReactDOMServer does not yet support Suspense.", so using this in Next.js does not seem possible until that changes.

[isaachinman]

Yes, there are multiple issues with react-i18next v10. It was a pretty eager release - we're going to wait on this end until some things are smoothed out.

The main thing is that it forces a React peer dep of >= 16.8.0, which is unacceptable at this time, in my opinion.

[jamuhl]

Suspense only get triggered if loading translation async -> serverside all translations should be loaded adding all needed namespaces to ns option on init and add all languages to preload option...

[isaachinman]

It's been about two months since the React v16.8.0 release - how do people feel about me rolling this out?

It'd force all consumers to have their React peer dep at >= 16.8.0. This is not the kind of peer dep discrepancy that will output warnings in your yarn install which you can ignore - it will be breaking.

What version of React are consumers of this package using? Are people relatively up-to-date?

[moribvndvs]

I think we're in a pretty good place where people who haven't advanced to 16.8 can use the current version, the only difficult part being what would appear to some devs as an arbitrary version number of 0.37 to work with <16.8. Nothing a nice headline on the readme can't fix, maybe with some angelfire-style marquees and rotating fire gifs.

[isaachinman]

@HackedByChinese Crucially, I _would not_ be supporting a <16.8.0 branch of this package. I believe that react-i18next has plans to support their v9 for awhile longer, but I simply don't have the resources to do that here. It's an all-or-nothing thing.

[jamuhl]

@isaachinman plan is to support v9 to mid 2019 - right - but yet never had a request for changes / fixes on that version - might be just luck...

[isaachinman]

We still have somewhat frequent bug/feature-parity requests over here, so I'm hesitant. That said, next-i18next has only been around for ~5 months so I wonder how many "legacy" consumers there really are.

[jamuhl]

My guess most devs will be on some v16.x - so an update to >= 16.8 should be no big pain. Not tested but migration of react-i18next should be rather straight forward renaming like https://react.i18next.com/latest/migrating-v9-to-v10#components-v9-greater-than-v10 and not using Suspense turning that off: https://react.i18next.com/latest/migrating-v9-to-v10#migration

But like everywhere there might be edge cases...even more on serverside...but as there are devs using v10 on there own SSR implementation already i think it should work...

[MathiasKandelborg]

I'd say go for it, I'm ready for the update and besides some probable edge cases... there shouldn't be much to worry about for anyone.

[haf]

If you can make it work SSR, do the upgrade. My 2 cents!

[isaachinman]

Currently blocked by https://github.com/i18next/react-i18next/issues/843.

[MiguelFreire]

@isaachinman That issue seems closed, any updates on this?

[isaachinman]

@MiguelFreire Yes, documentation was provided. It's now unblocked as far as I know, but I haven't had time to pick the work back up.

[isaachinman]

I now believe #330 is ready for early adopters to test and let me know if they find any issues.

@lucasfeliciano @beheh @HackedByChinese @MathiasKandelborg @MiguelFreire Would any of you be willing to install this branch into your projects and do a bit of testing/QA?

All tests are passing (we've dropped hands-on handling of Trans), but I'd like to be sure.

[lucasfeliciano]

I'll test it out this week.
Later on Thursday :)

[tumidi]

I'm using v0.41.0 and it's working fine. :pray:

Except the useTranslation hook is not exported. Is this planned?

[isaachinman]

Hey @tumidi. In reality we probably should not be exporting Trans either. This package should only re-export things that it needs to modify. Can you import useTranslation from react-i18next directly? My naive assumption is that this should work given an appropriate i18next context provider.

[novascreen]

hey @isaachinman that's what i ended up doing, in that case react-i18next should maybe be a peer dependency? my eslint rules in this case complain about react-i18next not being installed. nothing that can't be fixed with a eslint-disable comment, but if you use react-i18next as a direct dependency i think it would make sense to re-export those things.

[isaachinman]

It's not a peer dep because not all users will need to interact directly with the react-i18next package. Open to suggestions here but I don't think there's a better way to go about this, as long as our dep declaration for react-i18next is sufficiently loose to allow for dependency flattening. Maybe we should be at ^10.0.0 instead of ^10.9.0.

[isaachinman]

In short: if you need to use react-i18next directly, install it directly. Your package manager _should_ be able to make sense of this.

[tumidi]

Hey @tumidi. In reality we probably should not be exporting Trans either. This package should only re-export things that it needs to modify. Can you import useTranslation from react-i18next directly? My naive assumption is that this should work given an appropriate i18next context provider.

Ah, I see. Confirming it works as expected. Thanks!