Okay got it. If you read the vuex documentation (https://vuex.vuejs.org/en/modules.html) carefully, not like I did, then you will find out that the ‘rootState’ is always passed on as third argument:

Also, inside module getters, the root state will be exposed as their 3rd argument…

This will allow you to access the route plugin and state.

@joeyezekiel, I think this happens if you use lazy load AND mess with the model (:nodes) after initialization. You might provide your own ‘lazy load’ implementation.

Using the Vue dev tools inspecting QTree’s state, I see that changes to “expanded.sync” are indeed reflected in the tree’s internal state. However, when reloaded, for every node in the expanded array the “@onlazyload” method would have to be fired, but this does not happen.
My assumption: the tree does only know about the nodes of the inital model provided. Since the “@onlazyload” handler is never triggered it will not load the children of the expanded nodes and keep them closed.

Okay got it. If you read the vuex documentation (https://vuex.vuejs.org/en/modules.html) carefully, not like I did, then you will find out that the ‘rootState’ is always passed on as third argument:

Also, inside module getters, the root state will be exposed as their 3rd argument…

This will allow you to access the route plugin and state.

The migration guide lists various use cases for app plugins, among them the usage of vuex-router-sync:

You want to interfere with the Vuex store instance - An example would be to use vuex-router-sync package

So that’s what I want to do, but I must miss something, because I can’t figure out how. First I installed the package ‘vuex-router-sync’ from here.

https://github.com/vuejs/vuex-router-sync

Then I created an app plugin called ‘router.js’ like this

// import something here
import { sync } from 'vuex-router-sync'

// leave the export, even if you don't use it
export default ({ app, router, store, Vue }) => {
 // setup sync
 const unsync = sync(store, router)
}

and registered the plugin in quasar.conf.js. The default function is called, I checked this. However, I cannot access the route from the state property in the store so it doesn’t get extended. What am I missing?

Greetings,
John

hi Slade,

thanks I will try. Async code during initialization, is it that uncommon?

John

hello,

so I’m in the process of migrating from 14.1 to 15.8 and trying to move some initialization code over to ‘App Plugins’. I’m using vue-apollo and previously I was adapting ‘main.js’ in order to first setup and then pass the ‘ApolloProvider’ object to Vue.
I’m trying to move this code to a separate plugin now. However, I doubt this actually makes sense, since I’m executing some ajax calls during setup of Apollo and ‘App plugins’ seem not to take this possibility into account. They do not expect a promise, but rather simply execute the exported default function. So my only possibility would be to make this function block and wait for reponses (or timeout). But maybe I just miss something.
How should we deal with async code in ‘App plugins’?

Greetings,
John