Skip to content

Documentation Clarity for Getters in Vuex Modules #1874

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

Closed
jmcooper opened this issue Nov 16, 2020 · 3 comments
Closed

Documentation Clarity for Getters in Vuex Modules #1874

jmcooper opened this issue Nov 16, 2020 · 3 comments
Assignees
Labels
3.x 4.x documentation Improvements or additions to documentation

Comments

@jmcooper
Copy link

Version

4.0.0-rc.1

Reproduction link

https://vuex.vuejs.org/guide/modules.html#namespacing

Steps to reproduce

This is a problem with the documentation.

What is expected?

Greater clarity on getters in Vuex modules

What is actually happening?

In the namespacing section there is this explanation for why getters, actions and mutations are not namespaced by default:
"By default, actions, mutations and getters inside modules are still registered under the global namespace - this allows multiple modules to react to the same mutation/action type."

That reasoning (allowing multiple modules to react) is true for mutations an actions, but it doesn't explain the purpose for getters. In fact, it feels inaccurate to be grouping getters into this reasoning since it's actually erroneous to suggest you can have getters with the same name in multiple non-namespaced modules (or root) when that, in fact, will produce an error.


What is the purpose for a module's getters being global by default? If there is a purpose, can it be included here in the documentation?

@kiaking
Copy link
Member

kiaking commented Nov 17, 2020

Good catch. Thanks for the feed back!

I think why getters are still registered globally is coming from historical reason, where when first we introduced modules, we believe we didn't had name spacing feature. So, we had to keep it global to avoid breaking changes.

How about we alter the text to:


By default, actions, mutations and getters inside modules are still registered under the global namespace - this allows multiple modules to react to the same mutation/action type. However, you must be careful that you can't define 2 getters with the same name or it will throw an error.

@kiaking kiaking added 3.x 4.x documentation Improvements or additions to documentation labels Nov 17, 2020
@jmcooper
Copy link
Author

jmcooper commented Nov 17, 2020

Hmm, having getters in that first sentence still feels troublesome. I'm also wondering if we could answer the question of "why" getters are global by default, or at least explain that it has no use in current versions, without making it feel too unprofessional. What about something like this:


By default, actions and mutations are still registered under the global namespace - this allows multiple modules to react to the same action/mutation type. Getters are also registered in the global namespace by default, however, this currently has no functional purpose and you must be careful not to define two getters with the same name in different, non-namespaced modules which will result in an error.

@kiaking
Copy link
Member

kiaking commented Nov 18, 2020

Nice. Maybe we should add a little more on "why". How about:


By default, actions and mutations are still registered under the global namespace - this allows multiple modules to react to the same action/mutation type. Getters are also registered in the global namespace by default, however, this currently has no functional purpose (it's implemented this way to avoid breaking changes) and you must be careful not to define two getters with the same name in different, non-namespaced modules which will result in an error.


Would you like to create a PR? Or I could too!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.x 4.x documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

2 participants