5.0.3
Chrome 73 / macOS Mojave 10.14
Open vue dev tools and check VUEX.
VUEX shows sometimes few minutes old state, even the page/application show correct data from VUEX. Also at first load VUEX shows init data of state, even there was triggered commits on VUEX using middleware in NUXT. After clicking trough application is VUEX updated correctly. Wrong is only base state of VUEX.
Probably to show missing actions and set correctly VUEX preview.
Showing only init state from VUEX - ignoring store actions from middleware in Nuxt on first load.
I'm not sure about how vue devtools is constructing current state, but this sounds like what may be the issue I'm facing. When I'm trying to look at current state it just infinitely spins. I also get an error in the console where it's trying to resolve a promise that functions as a blocker, but is no longer a promise (after initial page loads).
If I don't attempt to load state, the application works as normal. This leads me to believe that the way it is being init'd for loading state is somehow not creating the blocking empty promise correctly.
Hope this helps, thank you for the fantastic tool and let me know if you want more info on this.
@samuells Please provide a runnable reproduction demonstrating the issue.
@Akryum I am also having problems with the new dev tools taking a very long time to load things if I do not open them before performing any actions. I am using an automatic module registration function you can see here: https://codesandbox.io/s/l2x44nj71l, unfortunately it does not work in codesandbox as require.context is not functioning but maybe this will help. If I open my application, perform a few actions and then attempt to load the vuex state it goes into a loop and logs do not mutate store state outside of mutation handlers loop indefinitely. Here is the error at cancel time:
Error: Script terminated by timeout at:
reactiveGetter@moz-extension://f7d7caeb-5cf3-4729-80a5-3513509b6525/build/backend.js:4642:19
_traverse@webpack-internal:///./node_modules/vue/dist/vue.runtime.esm.js:2122:19
_traverse@webpack-internal:///./node_modules/vue/dist/vue.runtime.esm.js:2118:19
_traverse@webpack-internal:///./node_modules/vue/dist/vue.runtime.esm.js:2122:19
_traverse@webpack-internal:///./node_modules/vue/dist/vue.runtime.esm.js:2122:19
_traverse@webpack-internal:///./node_modules/vue/dist/vue.runtime.esm.js:2118:19
_traverse@webpack-internal:///./node_modules/vue/dist/vue.runtime.esm.js:2122:19
_traverse@webpack-internal:///./node_modules/vue/dist/vue.runtime.esm.js:2122:19
traverse@webpack-internal:///./node_modules/vue/dist/vue.runtime.esm.js:2099:3
get@webpack-internal:///./node_modules/vue/dist/vue.runtime.esm.js:4478:7
run@webpack-internal:///./node_modules/vue/dist/vue.runtime.esm.js:4542:22
update@webpack-internal:///./node_modules/vue/dist/vue.runtime.esm.js:4530:10
notify@webpack-internal:///./node_modules/vue/dist/vue.runtime.esm.js:731:13
reactiveSetter@webpack-internal:///./node_modules/vue/dist/vue.runtime.esm.js:1056:11
reactiveSetter@moz-extension://f7d7caeb-5cf3-4729-80a5-3513509b6525/build/backend.js:4665:16
mapOrganizationChildSitePI@webpack-internal:///./src/vuex/modules/organizations.js:343:5
mapOrganizationSpecialtiesAndChildSitesPI@webpack-internal:///./src/vuex/modules/organizations.js:361:118
organizations@webpack-internal:///./src/vuex/modules/organizations.js:382:14
wrappedGetter@webpack-internal:///./node_modules/vuex/dist/vuex.esm.js:742:12
resetStoreVM/</computed[key]@webpack-internal:///./node_modules/vuex/dist/vuex.esm.js:542:42
get@webpack-internal:///./node_modules/vue/dist/vue.runtime.esm.js:4467:25
evaluate@webpack-internal:///./node_modules/vue/dist/vue.runtime.esm.js:4572:21
computedGetter@webpack-internal:///./node_modules/vue/dist/vue.runtime.esm.js:4822:17
get@webpack-internal:///./node_modules/vuex/dist/vuex.esm.js:544:26
studies@webpack-internal:///./src/vuex/modules/studies.js:551:25
wrappedGetter@webpack-internal:///./node_modules/vuex/dist/vuex.esm.js:742:12
resetStoreVM/</computed[key]@webpack-internal:///./node_modules/vuex/dist/vuex.esm.js:542:42
get@webpack-internal:///./node_modules/vue/dist/vue.runtime.esm.js:4467:25
evaluate@webpack-internal:///./node_modules/vue/dist/vue.runtime.esm.js:4572:21
computedGetter@webpack-internal:///./node_modules/vue/dist/vue.runtime.esm.js:4822:17
get@webpack-internal:///./node_modules/vuex/dist/vuex.esm.js:544:26
contactStudyAffiliations@webpack-internal:///./src/vuex/modules/contacts.js:473:19
wrappedGetter@webpack-internal:///./node_modules/vuex/dist/vuex.esm.js:742:12
resetStoreVM/</computed[key]@webpack-internal:///./node_modules/vuex/dist/vuex.esm.js:542:42
get@webpack-internal:///./node_modules/vue/dist/vue.runtime.esm.js:4467:25
evaluate@webpack-internal:///./node_modules/vue/dist/vue.runtime.esm.js:4572:21
computedGetter@webpack-internal:///./node_modules/vue/dist/vue.runtime.esm.js:4822:17
get@webpack-internal:///./node_modules/vuex/dist/vuex.esm.js:544:26
stringify@moz-extension://f7d7caeb-5cf3-4729-80a5-3513509b6525/build/backend.js:2419:14
stringify@moz-extension://f7d7caeb-5cf3-4729-80a5-3513509b6525/build/backend.js:250:65
replayMutations@moz-extension://f7d7caeb-5cf3-4729-80a5-3513509b6525/build/backend.js:12129:84
initVuexBackend/<@moz-extension://f7d7caeb-5cf3-4729-80a5-3513509b6525/build/backend.js:12032:22
emit@moz-extension://f7d7caeb-5cf3-4729-80a5-3513509b6525/build/backend.js:3205:5
_emit@moz-extension://f7d7caeb-5cf3-4729-80a5-3513509b6525/build/backend.js:3028:12
Bridge/</<@moz-extension://f7d7caeb-5cf3-4729-80a5-3513509b6525/build/backend.js:2953:42
Bridge/<@moz-extension://f7d7caeb-5cf3-4729-80a5-3513509b6525/build/backend.js:2953:18
listener@moz-extension://f7d7caeb-5cf3-4729-80a5-3513509b6525/build/backend.js:2675:13
The error to not mutate refers to a line in my code where I am returning mapped data from a getter but I copy the data before mutating it so there shouldn't be a problem there.
update: Looks like this might actually be an issue with how I'm modifying the data and the slow down is just all the console logs of the errors, I'll fix it and test again. Is there a difference in how state changes outside of mutations are being detected as I had no complaints from vue tools 4.X.
To follow up on my issue, I had a mutation what was modifying the state but I did not see any errors until attempting to load the state, where it would go into a loop and print the "do not mutate store state" error indefinitely. I attempted to reproduce using a simple store here: https://codesandbox.io/s/l2x44nj71l and if you open the webpage in a new browser window and access the store state there are no errors despite modifying the store state in the getter.
@abelgoodwin1988 Upgrading to 5.0.6 fixes the issue for me.
@quannt Still a no-go on 5.0.6 for me.

@abelgoodwin1988 try fixing the TypeError shown on your console. Just add a check, something like
state && state.campus_configP && state.campus_configP.resolve && typeof state.campus_configP.resolve === 'function'
I got the same issue after upgrading to 5.0.6, fixed my TypeError and all was good. Seems like the Devtools was trying to re-run all the mutations?
I can't get nuxt.js & vue.js devtools to work - every commit I have to click Load State
Most helpful comment
I'm not sure about how vue devtools is constructing current state, but this sounds like what may be the issue I'm facing. When I'm trying to look at current state it just infinitely spins. I also get an error in the console where it's trying to resolve a promise that functions as a blocker, but is no longer a promise (after initial page loads).
If I don't attempt to load state, the application works as normal. This leads me to believe that the way it is being init'd for loading state is somehow not creating the blocking empty promise correctly.
Hope this helps, thank you for the fantastic tool and let me know if you want more info on this.