Skip to content
This repository has been archived by the owner on Nov 26, 2021. It is now read-only.

Cannot read property 'runtime' of undefined in unit tests #832

Closed
VladZen opened this issue May 8, 2020 · 1 comment
Closed

Cannot read property 'runtime' of undefined in unit tests #832

VladZen opened this issue May 8, 2020 · 1 comment

Comments

@VladZen
Copy link

VladZen commented May 8, 2020

I have a problem in my unit tests only:

TypeError: Cannot read property 'runtime' of undefined
at ModuleCollection.unregister (node_modules/vuex/dist/vuex.common.js:219:28)
      at Store.unregisterModule (node_modules/vuex/dist/vuex.common.js:512:17)
      at Object.<anonymous>.module.exports (node_modules/vue-tables-2/compiled/state/register-module.js:19:17)
      at Object.<anonymous>.module.exports (node_modules/vue-tables-2/compiled/mixins/created.js:9:5)
      at VueComponent.created (node_modules/vue-tables-2/compiled/v-server-table.js:65:7)

After some research I figured out that users are stuck with the same problem using SSR. For example, vuejs/vue2-ssr-docs#137 (comment) . Diving deeper I discovered that It also can be rooted from the dynamic registration of the vuex module inside created hook instead of beforeCreate

Possible solutions:

  1. if (self.$store && self.$store.state && self.$store.state[self.name]) {

    I suppose it could be better to check out the existence of the registered module using https://vuex.vuejs.org/api/#hasmodule

  2. Move the registration of the module inside beforeCreate instead of created

These all things are just assumptions. I will try to test them and let you know if I come up with something.

@VladZen
Copy link
Author

VladZen commented May 8, 2020

I was wrong and my error rooted from another reason. But still this can be changed to https://vuex.vuejs.org/api/#hasmodule . This functionality has been implemented recently in
vuejs/vuex#834

If someone is interested: I defined a property in the state mock, which name was the same as registered component. But I found out, that changing condition of unregistering of the module to self.$store && self.$store.hasModule(self.name) did the trick and prevented Store.unregisterModule from being called with the name of a nonexistent module.

This fact says, that self.$store.hasModule API has more stable logic because it relies on isRegistered property.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant