Teach how stubbing vue-i18n directives,filters,mixins

[renoirb]

Or anything that isn't a build dependency, but would be at usage time.

When creating our own component library, some components might be heavily leveraging render functions and some spots might become arguments passed to v-t="foo" directive {{ $t(foo) }} or {{ foo|translate }}.

vue-i18n docs doesn't show examples of stubbing (I shall link to respective project, of course).

Question might be better as a Vue.js documentation use-case for Vue inject feature, but when creating a library that will be imported as dependency but won't require i18n in its build steps.

Thank you for considering.

[chrisvfritz]

Good question! 🙂 I haven't used vue-i18n much personally, but I think what you're looking for is Vue Test Util's stubs and mocks (of which I have some examples in tests/unit/setup.js. Does that solve your problem?

[renoirb]

I guess what I'd have to do is use such a setup also imported at library build time, and when I import it from the project using it (nuxt, a project like yours (kudos!!)) I'd add to the root Vue(...).

That is assuming your proposal already handles letting actual implementation take over when detected. (I gotta review code about that just now)

Assuming my assumptions are correct with your instruction, Yup, It answers my question :)

[renoirb]

On a related note, something that looks similar to this, maybe by making a mixin for "t" method. Element UI does it like this (notice Locale and "t" method that gets imported)

I will report more notes here as i work on that.

[chrisvfritz]

Sounds good. 🙂 In setup.js however, we don't actually add much to the root Vue. Instead, we use createLocalVue, provided by Vue Test Utils, which can help you avoid modifying the global Vue. So for example, this can allow you to check that $router.push was called with specific arguments without sharing the same mock between all your tests. Does that make sense?

[chrisvfritz]

Closing for now, unless there's something more we can do here. 🙂

[renoirb]

I was hoping we could have a sample of how to make a component library that’s "i18n" aware. But in the end, it's already covered by Vue's Inject system. Maybe we could document that use-case in the docs. But not here. What do you think? (Thanks!)

[chrisvfritz]

Hm, I feel like the vue-i18n docs might be the best place for that. Do you think that would work?

[renoirb]

Makes sense. I can open an issue and see if I can factor out some of my findings in a PR, there.

[chrisvfritz]

Sounds great! Thanks. 🙂