Getters Approach

[bencodezen]

I'm reading over the docs for getters in Pinia and did some testing to figure out that there are two patterns people can use:

1. Using the this context through non-arrow functions
2. Passing in the state / getters directly through arrow functions

If I'm not mistaken, all of these patterns are valid:

export const useStore = defineStore('main', {
  state: () => ({
    counter: 0,
  }),
  getters: {
    // Non-Arrow Functions
    doubleCount() {
      return this.counter * 2
    },
    doublePlusOne(): {
      return this.doubleCount + 1
    },
    // Arrow Functions (Cannot use `this`)
    tripleCount: state => {
      return state.counter * 3
    },
    triplePlusOne: getters => {
      return getters.tripleCount + 1
    },
  },
})

I'd like to update the docs to reflect these patterns if possible, but wanted to see if there were any pros or cons between the two that I should know about.

[posva]

The last pattern is the only one that doesn't work because it's not technically possible (or didn't find a way) in TS to infer the getters, maybe it is possible in a way by excluding the current one.

I personally prefer recommending the arrow function one when possible because you don't need to type the return but you cannot use other getters while the regular function one, which is way more verbose, requires you to type the return value but can use other getters

[bencodezen]

So the limitation on doing it with arrow functions for getters purely is a TypeScript aspect then? Because if I'm not mistaken, it works in JS.

[posva]

Yes, you are right. I likely pass the store instance itself as an argument but I do believe that if it doesn't work in TS, it shouldn't be documented nor used (especially because the regular function with this works).

[bencodezen]

Got it. And it looks like with Actions, we're also recommending to stay with the this context too then right? And avoiding arrow functions as a whole besides the state itself.

[posva]

yeah, actions without access to this do not make sense because they can only access the rest of the store through the context, state isn't passed as an argument since you are free to pass whatever you want

[BenShelton]

Just to add this TS limitation is the same in Vue computed properties too, see https://vuejs.org/v2/guide/typescript.html#Annotating-Return-Types

This has been noted for Vue in vuejs/vue#7394 though the linked TS issue microsoft/TypeScript#18805 seems to suggest that this may work now, so maybe we won't need to do this in the future.