Next-i18next: suggestion: router/next middleware to autolink by lang variable

[andylacko]

Hello, I use localeSubpaths with import { Link } from '../config/i18n' and it works really well.

When I need to use push('/url') from react/router , I need to set subpath every time according to locale variable, I would prefer approach of importing {Router} from '../config/i18n' which would be middleware for standard next router that would be prefixing urls automatically with locale as

I18nRouter.push('/media')
// to 
I18nRouter.push('/en/media')
// or
I18nRouter.push('/media') // if default locale

[capellini]

I like this suggestion. Though I could conceptually think about how this would work, I want to make sure that I fully understand the "ins and outs" of Next.Router before doing so. We would also probably need to provide a wrapper for the withRouter HoC.

[andylacko]

With router is even better idea 👍

But it should work also outside components, for example I use Router.push in redux actions and sagas, HOC approach doesn't cover usage in actions

[isaachinman]

Duplicate of #4. If people are actually interested in this, I can reopen it. Just comment there. That said, it might be a better idea in this case to support imperative Router.push use instead of a HOC, so that people can do things outside the React component tree (eg in MobX/Redux actions and so on).

I believe @timneutkens may have had a reason why the HOC is preferable, though?

[capellini]

To clarify, my suggestion is that we wrap _both_:

1. Next's Router and
2. their withRouter HoC.

I _think_ that doing 1 would naturally lead to 2.

IMO, the HoC is preferable in instances where you would need information about the current route, like we do in appWithTranslation. In this case, we need the current URL object and the asPath in order to modify it if localeSubpaths is enabled.

But supporting imperative Router.push, Router,replace, etc, would also be needed.

[isaachinman]

Probably all that will happen prior to a 1.0 release is that we expose lang path utils so that "advanced" users can import them and use them for their own imperative routing.

There's a lot going on in this package at the moment and I don't want to commit to any new features/API changes prior to 1.0.

@capellini Do you agree?

[isaachinman]

Either way, I'm going to close this issue and reopen #4. Let's discuss there!

[capellini]

@isaachinman Yes, I agree.