Yep, I was also thinking of using registerModule(), but my store uses modules itself, so I had to hack it in another way. That’s the dirtiest thing I’ve ever done in my dev life…
In your App.vue, you specify the $store in Vue’s beforeCreate hook, before the reactivity is initialized. And to create the store, you simply get a reference to Vuex via the component’s $root, which is the Kirby app, then access constructor, which is Kirby’s Vue object, then access that object’s registered plugins, and finally use the 4-th entry there, because it happens to be Vuex:
<template>
...
</template>
<script>
export default {
beforeCreate () {
var Vuex = this.$root.constructor._installedPlugins[4]
this.$store = require('./store')(Vuex)
}
}
</script>
The main downside to this is that since I have to require() the store dynamically, it and all of its dependencies can’t use ES6 imports, which kind of sucks.
But using this hack, everything seems to function normally and I don’t have the reactivity problem I described above. What we need is for Kirby to expose the Vue and Vuex objects in the window so that plugins can use them. I’ve described that here as an idea. It would be blissful if the devs scheduled this for the next Kirby update.