feat: Dynamic route parameters translation

[paulgv]

What's new?

Adds support for translating dynamic route parameters via the Vuex store module

BREAKING CHANGE: preserveState is now set automatically when registering the store module and
cannot be set via the configuration anymore

So why do we need this?

When using switchLocalePath to create a global lang switcher component, there's currently no way for the method to know how to translate dynamic parameters. This is an attempt to address this issue.

How to test this?

This has been published as a prerelease on NPM, to test this version, install v6.0.0-0 with Yarn:

yarn add [email protected]

Or NPM:

npm i [email protected]

Refer to the new documentation section to see how to use this in your app: Dynamic route parameters

close #79

[codecov]

Codecov Report

Merging #345 into 6.x will not change coverage.
The diff coverage is n/a.

@@         Coverage Diff         @@
##            6.x   #345   +/-   ##
===================================
  Coverage   100%   100%           
===================================
  Files         2      2           
  Lines         6      6           
===================================
  Hits          6      6

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 918ae89...cce3774. Read the comment docs.

[paulgv]

@rchl If you get the chance to have a look at this, please let me know what you think.

[rchl]

Thank's for for reaching out to me to get my opinion.

I'm gonna keep looking more and thinking about it but first thing that comes to my mind is that I don't like the fact that this feature is dependant on store. I have personally never used i18n store as I didn't see the point of it. All it seems to do for me is duplicating all translation strings
that are already available in bundles, making page slower to load. So I would prefer that this feature doesn't require one to enable store. From the top of my head, I don't have better solution but maybe we can think of something :).

[rchl]

Wouldn't it be simpler if switchLocalePath accepted an optional object with that information that is currently passed through store?

[rchl]

Alternatively, I wonder if completely declarative approach is possible. That is, extract that information from pages at built time and maybe use Route object to store that information (Route.meta maybe)...

[paulgv]

Thanks for the feedback @rchl

Wouldn't it be simpler if switchLocalePath accepted an optional object

I think that users typically don't want to call switchLocalePath more than once in the app. It's pretty easy to create a LangSwitcher component and render it in the layout without having to think about special cases like the one we're trying to address here. I feel like pages need to be able provide parameters translations seamlessly and let switchLocalePath deal with these parameters "backstage".

extract that information from pages at built time

Since we're dealing with dynamic paths here, we can't really get the required data at build time because it might result in huge payloads in router meta if we were to handle all possible parameters & translations for all dynamic routes. Additionally, since the data will most likely grow between each build, the router will frequently be out-of-sync with the database.

I would prefer that this feature doesn't require one to enable store

Agreed. I ended up going for this solution even though I'm not a fan of it because I can't seem to make anything else work properly. Ideally, I'd like nuxt-i18n to expose a custom method trough pages components $options, that would return translated route parameters and the module would handle the rest. But we still need to make that data accessible globally for switchLocalePath to have access to it wherever it's used, while still being consistent on both the server and the client-side, which always a feels a bit tricky to me. I tried another solution where I injected a global Vue.observable that would serve as single purpose store but its state was lost on the client-side and I couldn't figure out why.

Any thoughts?

[paulgv]

Wouldn't it be simpler if switchLocalePath accepted an optional object

To clarify my thoughts here. I think that your suggestion would absolutely be valid and we probably should implement it anyway. But if I'm not mistaken, it's not compatible with using a "global" lang switcher in the layout, it would require users to render the lang switcher in every page, specifying translated parameters where needed, which could get a bit tedious in large applications.

[rchl]

Good point about having language switcher in the layout. Then that wouldn't work if data would be returned from page's asyncData. Didn't think of that.

In that case I guess we should go for current solution. I wonder though, given that it will be a major version, should we disable setLocale and setMessages mutations by default? I feel like it's something that not many people need but it can add a lot of heft and users might not even realize that.

[rchl]

Seems OK to me. Feel free to either address my comments or not. :)

[paulgv]

Thanks for the great suggestions @rchl, I'll address them ASAP.