Feature: Manually install `vuex/types/vue.d.ts`

[blake-newman]

This is a breaking change

What problem does this feature solve?

With module merging in TS, we can override module interfaces. However it is limited, in the case of the Vuex types it's impossible to compose full typing layer in components.

If we make it optional to install vuex/types/vue.d.ts then we can do our own manual declaration. Which will enable fully typed structures. I would also rename to vuex/types/install.d.ts

What does the proposed API look like?

Once we allow custom installation we can do something similar to this to enable full typing layer.

import Vue from 'vue'
import * as Vuex from 'vuex'
import { RootState } from 'store/types'

Vue.use(Vuex);

export class Store {
  store: Vuex.Store<RootState>;

  static instance: Store;

  constructor() {
    this.store = new Vuex.Store<RootState>{
      strict: true
    });
  }

  get() {
    return this.store
  }
}

declare module "vue/types/options" {
  interface ComponentOptions<V extends Vue> {
    store?: Vuex.Store<RootState>;
  }
}

declare module "vue/types/vue" {
  interface Vue {
    $store: Vuex.Store<RootState>;
  }
}

export default Store

[ktsn]

I agree that we should manually declare $store on Vue instance type.
But I also think there are no need to do that for ComponentOptions. It might be better to separate instance type augmentation and component options type augmentation.

[mitchell-garcia]

This would be a huge boost in productivity for us Typescript users - current examples are extremely verbose, especially when it comes to writing getters. In order to get static typing on any namespaced property from the $store, you have to write a getter and a storeAccessor (provided by vuex-typescript) for it.

import { getStoreAccessors } from 'vuex-typescript';

export const getters = {
    getProperty(state: ExampleState) {
        return state.property;
    }
}

const { read } = getStoreAccessors<ExampleState, ExampleRootState>('example');

export const getProperty= read(getters.getProperty);

Being able to specify the structure for this.$store on a per-project basis would save so many hours of work, I would like to pick this up if it's agreed that it would be the right direction.

[yyx990803]

I think this is a good idea, my only concern is backwards compatibility since we just released a new major version. Is there anyway to tell TS not to use the included types?

[blake-newman]

As far as I can see no, looks like it'll be a complete breaking change. If doing that we may aswell plan to improve typing layer where we can.

@ktsn has done some awesome work over here.
https://github.com/ktsn/vuex-type-helper

[skovmand]

+1 for this.

I came here to start the same discussion.

We currently solve this by manually type casting this.$store to our own store interface to get typed variables from the store. It gets pretty verbose writing (<OurStore>this.$store). If we could define type of this.$store globally, it would solve this.

interface OurState {
  search: {
    query: string | null;
    results: ImageSearchResult[];
    viewType: boolean;
  }
}

interface OurStore extends Store<OurState> {}

export default Vue.extend({
  name: "search-result",
  template: searchResultTemplate,
  computed: {
    results(): ImageSearchResult[] {
      return (<OurStore>this.$store).state.search.results;
    },
    viewType() {
      return (<OurStore>this.$store).state.search.viewType;
    }
  }
})

[blake-newman]

I will move this to a discussion thread, as there is more we can do to make the Vuex API more type friendly.

[skovmand]

Sounds good. Will the discussion remain here, or can you give us a link to it?

[blake-newman]

I will add a link, forming the thread atm including details on current issues.

[blake-newman]

@ktsn Has done some great work in getting Vuex more type safe. Thus this issue can be solved with his work, as we can do a major semver upgrade