Upgrade <Link> to reflect changes for dynamic routing

[shunkakinoki]

Hi once again! Thanks for the awesome project

Since v9.5.3, it seems like the component was updated for dynamic routing,
making the prop as= behave as href=

Updating the canary package to reflect this would be great!

Links:
vercel/next.js#16774
vercel/next.js#16634

[aralroca]

Thanks to report it! This will be solved in the next release!

[aralroca]

With the PR I've done it solves at the moment all the dynamic routes except the case of using a custom server. The reason is that Next.js now forces an error when the href and as don't match. And for custom server it is necessary that there is the language as prefix in the as ...

An alternative to solve this would be to change the middleware to redirects.

Maybe I can merge the current PR leaving the custom server part for another PR later so that it doesn't block. What do you think about this @shunkakinoki ?

[shunkakinoki]

@aralroca Thanks for the awesome work as always!!!
Definitely, a middleware approach would work for sure, to pass the PR. 🙇
Though with that being said, I'm not a user of the next.js custom server approach, so maybe the community will think otherwise.
Perhaps a canary version with warnings issued for custom server users for the time being?

[aralroca]

I reopen the issue because although I have merged the PR because it didn't block, we still need to solve the navigation with dynamic-routing + custom server

[aralroca]

@shunkakinoki I prereleased the PR under 0.17.3-canary.4 if you want to try it.

[shunkakinoki]

Thank you so much! You're the best

[aralroca]

From version 9.5.7 of Next.js, the Next.js Link component itself will have the same functionality as the next-translate Link.

I share the documentation on the subject:

https://github.com/vercel/next.js/pull/18067/files

This means that maybe we can deprecate the Link and Router from next-translate so that people can use the Link and Router from Next.js directly. You will only have to replace lang with locale.

It is still experimental, and we will have to make several tests before. So for the moment, I don't close this issue. But for me, it makes sense to evolve around here, since the same functionality that I implemented will now be in the Next.js core.