mapState doesn't work with non namespaced module

Version

3.1.1

Reproduction link

https://codesandbox.io/s/vuex-issue-with-mapstate-5zb3x

Steps to reproduce

In the reproduction link, there is a non namespaced module with has a count in it’s state and a doubleCount in it’s getters.

In the HelloWorld component I am trying to use vuex helpers to access the state and the getters like:

...mapState(['count']),
...mapGetters(['doubleCount]')

What is expected?

Since the module it’s not namespaced I should be able to access the state and getters of the module with vuex helpers.

Both mapState and mapGetters should work fine.

What is actually happening?

However, only the mapGetters helper it’s working.

---

In order to get the mapState to work I should do:

    ...mapState({
      count: state => state.myModule.count
    })

However IMHO, the mapState should work with just a string since the module in the end it’s merged with the global store.

[chromice]

@maeldur While technically you are correct, from user perspective it’s the source of confusion.

I can map state of my namespaced modules like this:

 ...mapState('myNamespacedModule', ['pieceOfState'])

…while for not-namespaced modules I have to use object/arrow functions:

...mapState({
  pieceOfState: state => state.myNotNamespacedModule.pieceOfState
})

At the very least mapState() should throw an error, if an array of state variables is passed to it without a namespace. Right now, it just creates computed variables with undefined values and the user (me in my case) stares blankly at the screen for 15 minutes trying to figure out what they are doing wrong.

[StephenHogsten]

Since state is not registered to the global scope, IMO mapState should accept the module name for non-namespaced state properties. It seems needlessly verbose when you’re pulling multiple properties from the state from the same module.

...mapState({
    firstProp: state => state.myNotNamespacedModule.firstProp,
    secondProp: state => state.myNotNamespacedModule.secondProp,
    thirdProp: state => state.myNotNamespacedModule.thirdProp,
    fourthProp: state => state.myNotNamespacedModule.fourthProp
})

versus

...mapState('myNamespacedModule', ['firstProp', 'secondProp', 'thirdProp', 'fourthProp'])

when the namespace property of the module doesn’t otherwise effect the access to state.

I also agree that an error or warning should be thrown when trying to use the map helpers for nonexistent properties, instead of secretly creating empty ones.