Allow function to be passed as namespace argument for mapState, mapGetters, mapMutations & mapActions

[aspruds]

What problem does this feature solve?

Right now I can set namespace when calling mapState. However, mapState only accepts string as a namespace. Unfortunately, I can not use Vue props values as these are only available after the component has been created. It means that I need to hardcode Vuex namespace and it is impossible to reuse the component.

What does the proposed API look like?

I would like the following functionality:

props: {
    namespace: {
        type: String,
        default: 'searchForm'
    }
},
computed: {
     // namespace in a function
  ...mapState(function() { return this.namespace }, ['username', 'password'])
},

To implement this, one would need to change mapState implementation. normalizeNamespace function would need to be called later (inside mappedState). Since mappedState is called only after the component has been initialized, it would be possible to resolve .namespace prop by calling the passed function.

I could provide a small code sample with my implementation (rewrite of current mapState) if that would help in any way.

[ktsn]

ref #748

[LinusBorg]

You could use mapState et al. in beforeCreate() to dynamically extend `this.$options.computed

[aspruds]

Another workarround which I am considering is to use vuex-connect.

[ktsn]

I think this is covered by passing a function to mapState/mapActions/mapMutations (related #924).
After releasing #924, we can dynamically change namespace of all store assets in mapXXX helpers.

{
  props: ['namespace'],

  computed: mapState({
    state (state) {
      return state[this.namespace]
    },
    someGetter (state, getters) {
      return getters[this.namespace + '/someGetter']
    }
  }),

  methods: {
    ...mapActions({
      someAction (dispatch, payload) {
        return dispatch(this.namespace + '/someAction', payload)
      }
    }),
    ...mapMutations({
      someMutation (commit, payload) {
        return commit(this.namespace + '/someMutation', payload)
      })
    })
  }
}

[men62]

Will the dispatch return promise? If yes, personally, is it good practice to assign the data from that?

[johnsoncheg]

@ktsn I'm surprised that when I use arrow function state => state[this.namespace], some errors about the this binding happen, I feel confused

[rATRIJS]

@ktsn it won't work neatly for deeper namespaces - e.g. level1/level2/level3 - as it would try to access it incorrectly:

mapState({
    someField: (state) => state["level1/level2/level3"].someField, // doesn't work
    someOtherField: (state) => state.level1.level2.level3.someOtherField, // works
});

To make it work you would have to replace / with . and use something like lodash.get().

[ktsn]

@rATRIJS Yes, the nested state need to be handled by kind of lodash.get style path access.

I'm closing this issue since this usage can be covered by #863 (comment).

[ThomasKruegl]

The workaround does not really improve the code in my opinion.

Workaround:

computed: ...mapState({
    state (state) {
      return state[this.namespace]
    },
    someGetter (state, getters) {
      return getters[this.namespace + '/someGetter']
    }
  }),

Code without mapState:

computed: {
    state () {
      return this.$store.state[this.namespace]
    },
    someGetter () {
      return this.$store.getters[this.namespace + '/someGetter']
    }
  },

The only thing mapState gives me in this case is getting rid of "this.$store."

The price is adding "...mapState" and the function parameters "state" and "getters" (state even unused in the case of getters).

I think i will go with something along the lines of Linus suggestion #863 (comment) for now, or implement some mapper on my own. Please think about better support for dynamic namespaces again :)

[brophdawg11]

I agree with @ThomasKruegl here in that the proposed workaround is not ideal as it makes for fairly different looking code throughout the app if you use a mix of statically and dynamically named modules.

With a static namespace:

computed: {
    ...mapState('static', [ 'foo' ]),
    ...mapState('static', {
        nestedBar: state => state.foo.bar
    }),
}),

If this feature was implemented as proposed, dynamic namespaces would look quite similar:

props: ['namespace'],
computed: {
    ...mapState(vm => vm.namespace, [ 'foo' ]),
    ...mapState(vm => vm.namespace, {
        nestedBar: state => state.foo.bar
    }),
}),

Compared to the proposed workaround, which looks and feels different - and loses the ability to use the shorthands provided by the array notation:

props: ['namespace'],
computed: {
    ...mapState({
        foo(state) {
            const path = vm.namespace.split('/');
            path.push('foo');
            return _.get(state, path.join('.'));
        },
        nestedBar(state) {
            const path = vm.namespace.split('/');
            path.push('foo');
            path.push('bar');
            return _.get(state, path.join('.'));
        },
    }),
}),

Even the workaround proposed by @LinusBorg above is a fairly significant deviation from the standard pattern and usage of mapXXX. Across a large codebase and a large team, I think the consistency of being able to use mapXXX both with a static string and with a dynamic namespace function is very important to consistency and maintainability of the code. It reduces cognitive overhead and should make onboarding new members much easier - as they'll be using the patterns documented in the Vuex docs in all scenarios - not learning new workarounds for these dynamic cases.

@ktsn Is there any chance you'd reconsider?