[Feature Request] Add mapFields

[alexhx5]

What problem does this feature solve?

Right now, you cannot use nested properties in v-model without writing a ton of unnecessary computed objects for each property:

Current way:

<input v-model="searchQuery">
<v-switch v-model="searchOptionsIncludeFiles"></v-switch>
<v-switch v-model="searchOptionsIgnoreCase"></v-switch>

computed: {
  searchQuery: {
    get () {
      return this.$store.state.search.query
    },
    set (value) {
      this.$store.commit('setSearchQuery', value)
    }
  },
  searchOptionsIncludeFiles: {
    get () {
      return this.$store.state.search.options.includeFiles
    },
    set (value) {
      this.$store.commit('setSearchOptionsIncludeFiles', value)
    }
  },
  searchOptionsIgnoreCase: {
    get () {
      return this.$store.state.search.options.ignoreCase
    },
    set (value) {
      this.$store.commit('setSearchOptionsIgnoreCase', value)
    }
  },
}

But it would be much better to just do it like this:

A better way:

<input v-model="query">
<v-switch v-model="includeFiles"></v-switch>
<v-switch v-model="ignoreCase"></v-switch>

computed: {
  ...mapFields([
    'search.query',
    'search.options.includeFiles',
    'search.options.ignoreCase',
  ])
}

What does the proposed API look like?

There's a module called vuex-map-fields, perhaps it would make sense to add something like this to Vuex?:

...mapFields([
    'search.query',
    'search.options.includeFiles',
    'search.options.ignoreCase',
])

[davestewart]

Take a look at Vuex Pathify:

https://github.com/davestewart/vuex-pathify

It does what you mention above and also can reach in to object properties without having to physically create separate mutations as you have with setSearchOptionsIgnoreCase.

In pathify you would write:

computed: sync('search', [
  'query',
  'options@includeFiles',
  'options@ignoreCase',
])

[alexhx5]

@davestewart thanks for letting me know about it, pathify does indeed look nice. It's unfortunate that Vuex doesn't have something like this built-in. Is it because Vuex supposed to be super lightweight?

[davestewart]

I can't speak on behalf of the authors, but my impression is that a) it was always meant to be explicit with top-level mutations b) they didn't want to deviate too far from the recognised Flux pattern.

There's not insignificant feeling in the community that Vuex / Flux is overkill for a lot of state management work. My hope is that over the next while we'll see even better / more flexible / less onerous state management patterns emerge, with Vuex / Flux being a stepping stone to them.

[qwesda]

Vuex should definitely have something like this.

Sure, for some things it makes sense to handcraft getters and setters, but writing a hundred trivial getters/setters get old very quickly.

The trivial cases should be easy and they should not introduce tons of completely useless code.

The good thing about things like v-model and mapState is that they signal to the reader "this is a completely unremarkable mapping/wiring of some state" – it makes the code more comprehensible and makes non-trivial things stand out.

And it should definitely be part of Vuex itself. Having 2nd-level dependencies is already a bit iffy, but 3rd-level is quite a no go – at least for me, since the likelihood of some library becoming unmaintained or simply not keeping up with upstream developments is getting more likely the further down your dependency tree goes.

[alexhx5]

Any thoughts on this issue, guys?

I agree with @qwesda, what if vuex-map-fields and vuex-pathify libraries are no longer maintained and stop working in Vue 3.

It would be really nice to have an option to let mapFields to do all the work for you, instead of having to manually code 2-way computed bindings and setting up all those mapState, mapGetters, mapMutations, mapActions, the way the specified above libraries do it.

[kiaking]

There're lots of discussion trying to make v-model work on Vuex. While I think this is really nice to have as an plugin, I think Vuex should stick to how Vue work in general.