Vuex getters

[ruiposse]

Hi guys. There's been something on my mind lately about Vuex that I'll try my best to explain here.

I understand that Vuex getters are meant to return a sub-set of the state and that's fine. I also kinda understand why they can't take arguments... because reasons (SSR) and stuff.

On a component, if I want to return, say, a product from the state I'd access it directly, something like state.products[productId] and that it would be fine.

Now say I would like to return a product by productName instead and let's say I would do it by iterating on the product array state until I find it. This is still fine and I would create a method on the component to deal with it. If I would like to share getProductByName method, I would put it onto a mixin and everything would be alright.

But... Wouldn't it be nicer if Vuex could provide me with a way of creating a file of "special" getters so that everything state related (even just reading that state) would be managed on the "Vuex side of things" ?

I think that literally what I'm saying is that Vuex could have a way of letting me pass arguments to "getters". Just for example sake, current getters would become reducers (because they return a sub-set of the state) and then the "new" getters would actually be able to take arguments to compute off. (I'm totally aware that renaming is not an option, since it would break compatibility, but hopefully it was useful for an argument sake) (also, sorry about reducers naming, because I didn't want to start a discussion on what Flux is not and what Vuex is 😄 ).

Any thoughts ?

[yyx990803]

I'm not sure if I understand you correctly, can you give some code to illustrate what kind of API you have in mind?

[dm]

@ruiposse @yyx990803 gotcha! 😄

[skyrpex]

I think he wants to be able to define getters with parameters, basically.

[pdcmoreira]

Woudn't it be awesome if, besides getters, we could have also computed properties and methods?

[ruiposse]

Basically, yes.

Anyway, thank you @yyx990803 for your answer on this topic yesterday at the London Vue.js Meetup 😄

I totally got your point that productName could actually be part of the state and updated accordingly which would in turn update the sub-set of the state via the getter. That works and it's totally fine.

For the sake of this discussion, here's an example of what I was trying to say (probably should've done it on the initial post, oh well, here it goes..):

• productPageRoute.vue - takes productName as a route parameter.

<template>
  <h1>{{ product.name }}</h1>
  <h2>{{ product.shortDescription }}</h2>
  <table>
    <tr><td>Date</td><td>Total</td></tr>
    <tr v-for="o in getProductOrderHistory(product.id)">
      <td>{{ o.date }}</td><td>{{ o.total }}</td>
    </tr>
  </table>
</template>

<script>
export default {
  data() {
    return {
      product: this.getProductByName(this.$route.params.productName)
  },
  vuex: {
    getters: {
      getProductByName: (state, productName) => {
        for (let p in state.products) {
          if (p.name === productName) {
            return p;
          }
        }
      },
      getProductOrderHistory: (state, productId) => {
        // return state.productsOrdersHistory array filtered by productId
      }
    }
  }
}
</script>

Obviously that in this example everything would be much simpler if the route just gets the productId as a route parameter, but that's not the point for this discussion.

It would be very good if we could read the state in a similar way that I showed on the example. I think it would make Vuex more pleasant to work with.

I know you're right @yyx990803 when you say that the argument needs to come from somewhere and that it can be in the state, since it is actually state of the app! But what if, as an example, there's something that needs to read the state (and it updates the state to achieve that) but it sits inside a v-for? Would this mean that we should update the respective state for each v-for iteration?

Thanks again!

[blake-newman]

I'd say the naming convention is slightly confusing, getters indicates state can be retrieved in any form, but in fact they are reducers.

Perhaps we should have reducers being pure methods. Which can be used for filtering, mapping ect.

getters then can be given any context. Similar to computed, but you can now combine computed props to getters in vuex option. Which helps structure of components.

This would create more flexibility for these scenarios.

[pabdon]

Hi,

If I understood well, in case we need a getter to feed a table, it will have to return the corresponding object to this table and than we need to build a v-for with this object in the template.

In same way, If we have more than one table to be chosen by the user, the getter would have to return the corresponding object to all tables.

Wouldn't be more flexible if the getters accept, in addition to state, arguments that serve to choose exactly which state's slice we want. These arguments could be the indice generated by a v-for or selecting an item from a list by the user.

[yyx990803]

In 2.0, getters are now defined in the store. To make them efficiently cachable, 2.0 getters must be pure too.

Also for the original request, the more appropriate approach is storing the current route state in the store as well. This way the getters has access to that information too.

If a component needs derived store state based on its own state, it should define a local computed property.

[fritx]

Does vuex getter have to be state => state.foo instead of (state, id) => state.foo[id]?
Is it possible for me to pass an extra argument to the getter?

[edouard-lopez]

When trying to pass extra argument I got the following:

[Vue warn]: Error when evaluating expression "function ping() {
            this.printer['site'] = this.site.id;
            return this.printerPing(this.printer);
        }": TypeError: this.printerPing is not a function (found in component: <printer>)

Getters

retrievePrinterPing(state, printer) {
    return state.pings[printer.site][printer.hostname];
}

Computed value

    computed: {
        ping() {
            this.printer['site'] = this.site.id;
            return this.printerPing(this.printer);
        }
    }

Vuex

getters: {
    pings: getters.retrievePings,
    printerPing: getters.retrievePrinterPing
}

Question

Any suggestion?

[ktsn]

If we want to allow extra arguments to getters, we can define the getter returning the function that receives extra arguments.

retrievePrinterPing: state => printer => {
  return state.pings[printer.site][printer.hostname];
}

[deiucanta]

@yyx990803 When using modules you can't get the route state inside the getter. For me, this is a MUST HAVE feature (allowing getters to have arguments).