VueI18n factory

[Silentscripter]

In some situations (for ex. micro-frontend environments where vue apps are wrapped in web-components) it would be good to have different VueI18n instances when a wrapped vue app is destroyed and recreated (since normally the VueI18n is created before and referenced in Vue component options).

[codecov-io]

Codecov Report

Merging #592 into dev will decrease coverage by 0.06%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##              dev     #592      +/-   ##
==========================================
- Coverage   96.18%   96.12%   -0.07%     
==========================================
  Files          10       10              
  Lines         786      799      +13     
==========================================
+ Hits          756      768      +12     
- Misses         30       31       +1

Impacted Files	Coverage Δ
src/index.js	97.79% <ø> (-0.24%)	⬇️
src/mixin.js	94.93% <ø> (+0.27%)	⬆️
src/components/interpolation.js	100% <ø> (ø)	⬆️

---

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 9eba9c4...cba8408. Read the comment docs.

[kazupon]

Thank you for your PR!

I don't get why you can't reuse the same i18n instance.
Could you provide more explanation please?

[Silentscripter]

hi kazupon, in micro-frontend architecture we usually wrap vue apps in webcomponent to reuse as independent widgets in other SPAs. As for vue component option design if you happen to destroy and recreate one of these apps (for ex routing from a page to another and back) you find the widget plugins (store, router, i18n for example) to maintain their state since even if the vue app is destroyed, the reference of the plugin that will be taken by the new vue app is the same.
Another case is when you use the same widget on the same page more than once: they share the same plugin instance under the hood and when you apply some commands on one (for ex. changing locale) it is replicated to the other.
With this addition you can assure that vue i18n is created on the vue root instance during the beforeCreate lifecycle and is assured to be linked to that vue app only.
Vuex, for example, has taken the same approach in its mixin beforeCreate hook.

[AndreaPaciolla]

Hi there,
any update about this issue?

It could be useful for me too.

[exoego]

Hi @Silentscripter 😄

Let me confirm our (vue-i18n maintainers) understanding regarding your description #592 (comment).

1. In some use cases (micro-frontent e.g), users can not simply reuse a single VueI18n instance for multiple components even if those components uses samely-configured VueI18n instances, because those have different lifecycle (created/destroyed).
2. However, creating samely-configured VueI18n instances everywhere result in dupliations of instantiation code.
3. So, if we can use a factory, we can define VueI18n instance configuration in one place, and reuse it everywhere.

Am I on the right track ?
If so, I think having factory in VueI18n totally make sense.

[Silentscripter]

hi @exoego ,

I confirm you are on the right track :)

[exoego]

@Silentscripter
Nice !!
Could you resolve conflict ?

[exoego]

LGTM

[exoego]

@kazupon
I will wait your review up to 2 weeks and eventually merge this PR.

[exoego]

@kazupon
Since I believe this PR improves DX for micro-frontend use case, I will merge this PR within one week, unless you leave change requests.

[kazupon]

@exoego
same PR is sent to vue-router.
vuejs/vue-router#2791

personally, I don't prefer micro-frontend, because it's complicated.
If the vue.js official ecosystem supports micro-frontend (if vue-router will be merged), vue-i18n follows it.

[Silentscripter]

@kazupon honestly I don't get your point. The fact you don't prefer micro frontend doesn't mean it should not be fine in certain situations. There are lots of blog posts and articles regarding the adoption of micro frontend architectures in various industries.
Also this change doesn't break the normal usage of the library.
Regarding the vue ecosystem, as already stated above, the Vuex package has been using this solution already, infact this pull request was inspired by the work done in vuex.

[AndreaPaciolla]

@kazupon I am following the thread because I'm involved in this topic too.
Micro-frontend is basically a tool which can be used or not. A recent architectural paradigm which is gaining room among others paradigms and patterns in the frontend world. I think it could be interesting, for vue-i18n, to support it, as an important library inside a progressive framework ecosystem.

Moreover, the solution proposed has been successfully adopted inside another vue-library, vuex, as mentioned by @Silentscripter

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.12%. Comparing base (9f5ff80) to head (cba8408).
Report is 86 commits behind head on dev.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@           Coverage Diff           @@
##              dev     #592   +/-   ##
=======================================
  Coverage   96.11%   96.12%           
=======================================
  Files          10       10           
  Lines         797      799    +2     
=======================================
+ Hits          766      768    +2     
  Misses         31       31           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[luckylooke]

Just to advocate micro-frontends architecture, here is one use case not mentioned:
We use micro-frontends architecture for migrating huge legacy code bases to Vue, it helps us progressively replacing app parts to Vue web components until they join into one SPA at the end of migration.
Thank you