Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TypeError: Cannot read property 'hasChild' of undefined #1850

Closed
urbnjamesmi1 opened this issue Oct 16, 2020 · 3 comments
Closed

TypeError: Cannot read property 'hasChild' of undefined #1850

urbnjamesmi1 opened this issue Oct 16, 2020 · 3 comments

Comments

@urbnjamesmi1
Copy link
Contributor

@urbnjamesmi1 urbnjamesmi1 commented Oct 16, 2020

Version

3.5.1

Reproduction link

https://jsfiddle.net/xkLh4njp/

Steps to reproduce

  1. Create a Vuex store.
  2. Call store.hasModule() with an array of at least 2 elements where neither module has been registered to the store.

What is expected?

store.hasModule() to return false

What is actually happening?

Error "TypeError: Cannot read property 'hasChild' of undefined" is thrown

@cuebit
Copy link
Member

@cuebit cuebit commented Oct 16, 2020

Thanks for opening this issue and creating a PR. However, this is expected behaviour at this time.

In the same manner as registerModule behaves, where a parent module must be registered before any descendants, the hasModule should verify the parent before verifying any descendants.

Negating the return type, when checking for a descendant where a parent module may not exist, implies the parent may exist when really you want this behaviour to be explicit.

@urbnjamesmi1
Copy link
Contributor Author

@urbnjamesmi1 urbnjamesmi1 commented Oct 19, 2020

Can the documentation for hasModule and registerModule at least be updated with this explanation? Or maybe a custom error can be thrown explaining that a specific parent module doesn't exist.

@cuebit
Copy link
Member

@cuebit cuebit commented Oct 22, 2020

For sure, this is an opportunity to offer clarity in the docs. I don't think throwing errors are a useful way to identify this concern, since the hasChild method naming is self explanatory in the error thrown when a child module cannot be reached.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants