feat: improve helper types for more type safety #1121

ktsn · 2018-01-04T16:39:10Z

This typings update allows to use typed getters/actions/mutations out of the box if they are used in the following manner.

1. Declare each store assets types as interfaces.

// State
export interface CounterState {
  count: number
}

// Getters
// key: getter name
// value: return type of getter
export interface CounterGetters {
  power: number
}

// Mutations
// key: mutation name
// value: payload type of mutation
export interface CounterMutations {
  increment: { amount: number }
}

// Actions
// key: action name
// value: payload type of action
export interface CounterActions {
  incrementAsync: { amount: number, delay: number }
}

2. annotate a namespaced module with DefineModule utility type.

The annotated assets must fulfill specified names and return type (getters) / payload type (actions, mutations). Also the assets types will be inferred.

The type in the following example should be fully inferred:

import { DefineModule } from 'vuex'

const counter: DefineModule<CounterState, CounterGetters, CounterMutations, CounterActions> = {
  namespaced: true,

  state: {
    count: 0
  },

  getters: {
    power: state => state.count * state.count
  },

  mutations: {
    increment (state, payload) {
      state.count += payload.amount
    }
  },

  actions: {
    incrementAsync ({ commit }, payload) {
      setTimeout(() => {
        commit('increment', { amount: payload.amount })
      }, payload.delay)
    }
  }
}

3. create typed namespaced helpers with createNamespacedHelpers.

Then, we can acquire typed mapXXX helpers for the defined namespaced module.

export const counterHelpers = createNamespacedHelpers<CounterState, CounterGetters, CounterMutations, CounterActions>('counter')

4. use the namespaced helpers in a component.

import { counterHelpers } from '@/store/modules/counter'

export default Vue.extend({
  computed: counterHelpers.mapState({
    value: 'count'
  }),

  methods: counterHelpers.mapMutations({
    inc: 'increment'
  }),

  created () {
    // These are correctly typed!
    this.inc({ amount: 1 })
    console.log(this.value)
  }
})

Caveats

Store is still not typed

I think it is probably impossible to infer the entire store type correctly since we cannot concat getter/actions/mutations names with namespace on type level. So this PR focuses how we do not use $store directly but use typed helpers instead.

It does not infer the types completely if passing functions to mapXXX helpers.

For example:

counterHelpers.mapState({
  foo: state => state.count
})

counterHelpers.mapMutations({
  bar (commit) {
    commit('increment', { amount: 1 })
  }
})

We can write the above code with inferred state and commit types but the component will have a type of foo: any and bar: (...args: any[]) => any.

It can be easily rewrite with a combination of object form mapXXX helpers and normal methods, so I think it would not be a problem.

Using root assets

The default mapXXX helpers still accepts any asset names and returns record of any type. To manually annotate them, we can use createNamespacedHelpers too. If we don't specify a namespace as an argument, it returns the root mapXXX helpers so that we annotate with root module assets types as same as namespaced modules.

const rootHelpers = createNamespacedHelpers<RootState, RootGetters, RootMutations, RootActions>()

fix #532
fix #564
fix #1119

HerringtonDarkholme · 2018-01-06T10:42:36Z

types/index.d.ts

  type: string;
 }

-export interface MutationPayload extends Payload {
+type Payload<K extends keyof P, P> = { type: K } & P[K]


Technically this is a breaking change. I don't know how frequent Payload is used, but this might be a compatible alternative:

type Payload<P = { [k: string]: {} }, K extends keyof P = keyof P> = { type: K } & P[K]

http://www.typescriptlang.org/play/#src=type%20Payload%3CP%20%3D%20%7B%20%5Bk%3A%20string%5D%3A%20%7B%7D%20%7D%2C%20K%20extends%20keyof%20P%20%3D%20keyof%20P%3E%20%3D%0A%20%20%20%20%7B%20type%3A%20K%20%7D%20%26%20P%5BK%5D%0A%0Adeclare%20var%20p%3A%20Payload%0A

I ended up reverting the rename of Payload 0858c6d

Yes, changing interface to type would be a breaking change. My mistake 😷

HerringtonDarkholme · 2018-01-06T10:43:57Z

Thanks! This is a long change so I think I need some time to review the change. Also, we need documentation update to catch up this new awesomeness. 😄

HerringtonDarkholme · 2018-01-06T10:59:08Z

types/helpers.d.ts

+type Computed<R> = () => R;
+type Method<R> = (...args: any[]) => R;
+type MutationMethod<P> = (payload: P) => void;
+type ActionMethod<P> = (payload: P) => Promise<any>;


I'm fine with untyped action return type. In fact, users can register multiple actions so the return type can't be checked any way.

HerringtonDarkholme · 2018-01-06T13:10:30Z

types/helpers.d.ts

+ * mapMutations
+ */
+interface MapMutations<Mutations> {
+  <M extends Mutations = Mutations, Key extends keyof M = keyof M>(map: Key[]): { [K in Key]: MutationMethod<M[K]> };


Usually generic default is for interface / type alias. Mapper is not exported nor augmented by users, so I think these defaults aren't required.

Actually, it throws error if Mutations is BaseType since M will be inferred as {} in that case. I have no idea how we fix it without default generic type 😞

But we may no longer need it if we create typed root helpers with createNamespacedHelpers in any cases.

Let's try typed root helpers! It looks more promising since it can return more precise types.

HerringtonDarkholme · 2018-01-06T13:30:10Z

types/helpers.d.ts

-  & MapperWithNamespace<Computed>
-  & MapperForState
-  & MapperForStateWithNamespace;
+export declare const mapState: RootMapState<BaseType, BaseType>;


The proposed usage is mapState<RootState>(['foo', 'bar']), however, the return type is RootState because foo/bar isn't participating inference.

Another usage is that we export RootMapXXX and slightly change their type.

export interface RootMapState<State> { <Keys extends keyof State>(keys: Keys[]): {[K in Keys]: State[K]} }

then users can write something like const myMapState: RootMapState<RootState> = mapState. Of course, it requires us to maintain more public types, and also looks a little bit bizarre to end users.

But it is more versatile in usage -- I think object style can be supported, and more precise in returning type.

How about reusing the pattern of createNameSpacedHelpers? Adding one more helper function like createRootHelpers? Implementation wise, it just return these root helpers, but it gives better developer experience for both end users and lib maintainers.

How about reusing the pattern of createNameSpacedHelpers

That sounds good idea. I think returning root helpers from createNamespacedHelpers with no argument would work. createRootHelpers would sound a bit weird for pure JS users.

Awesome! Great balance between types and runtime behavior.

HerringtonDarkholme · 2018-01-06T16:35:47Z

types/utils.d.ts

+ * `ExtraGetters` is like `Getters` type but will be not defined in the infered getters object.
+ * `RootState` and `RootGetters` are the root module's state and getters type.
+ */
+export type DefineGetters<


What about a one-for-all option? like :

export type DefineStore< Actions, State, Getters, Mutations, ExtraActions = {}, RootState = {}, RootGetters = {}, RootMutations = {}, RootActions = {} > = { // .... }

Yes, it looks better since we always combine all assets for module 😄
I will rewrite the utility types.

ktsn · 2018-01-09T05:26:34Z

documentation update

I will write docs for this. Thanks for pointing it out!

Demivan · 2018-01-09T09:00:30Z

types/helpers.d.ts

+ * mapMutations
+ */
+interface MapMutations<Mutations> {
+  <M extends Mutations = Mutations, Key extends keyof M = keyof M>(map: Key[]): { [K in Key]: MutationMethod<M[K]> };


There is a problem with returning MutationMethod here.
MutationMethod does not have ...args: any[] parameters anymore.
This makes all mutations take one argument, same goes for actions.

It's not actually a problem because mutations and actions only accept one parameter. The returned methods will never process 2nd or latter parameters.

This worked for me before

You can pass multiple parameters (or none) to mapped actions

Ah, I see. It should be an optional argument in default to follow the existing behavior.

But I think if we annotate types via createNamespacedHelper explicitly, it should not be an optional. Because it easily breaks apps if the user adds a payload for actions/mutations with no payload and the type checker cannot detect that.

If the users want to declare non-payload actions/mutations, they should explicitly pass a null or undefined value.

@HerringtonDarkholme What do you think?

I agree that users should explicitly pass null or undefined.

I agree, i believe undefined is probably best to signal that this payload is void. null could have context to an application where undefined can't be used on the store as it breaks the reactivity principles.

…ateNamespacedHelpers

HerringtonDarkholme · 2018-01-10T02:13:49Z

types/helpers.d.ts

-  <Key extends keyof Mutations>(map: Key[]): { [K in Key]: MutationMethod<Mutations[K]> };
-  <Map extends Record<string, keyof Mutations>>(map: Map): { [K in keyof Map]: MutationMethod<Mutations[Map[K]]> };
+interface MapMutations<Mutations, Type extends MethodType> {
+  <Key extends keyof Mutations>(map: Key[]): { [K in Key]: MutationMethod<Mutations[K], Type> };


This typing still requires all methods in mutation/action are homogeneous: all methods either require one parameter at the same time or don't accept parameter at all. We cannot declare such mutations that some methods require parameter while others don't at the same time.

Yes, I intend that behavior. I leave them optional if the users do not annotate types because they probably want flexible syntax like in JS. On the other hand, the methods always require an argument if they annotate types because they probably want type safety in that case.

HerringtonDarkholme · 2018-01-10T02:36:09Z

docs/en/api.md


  Create namespaced component binding helpers. The returned object contains `mapState`, `mapGetters`, `mapActions` and `mapMutations` that are bound with the given namespace. [Details](modules.md#binding-helpers-with-namespace)
+
+  If the namespace is not specified, it returns the root mapXXX helpers. This behavior is convenient to annotate strict types for mapXXX helpers.


Hmmm, what about

This is mainly for TypeScript users to annotate root helper's type.

Mentioning TypeScript explicitly makes JS users know annotating type doesn't require much care for them.

It sounds clearer than before. Thanks!

HerringtonDarkholme · 2018-01-10T02:41:09Z

types/index.d.ts

@@ -12,9 +12,7 @@ export {
 } from "./helpers";

 export {
-  DefineGetters,


IMHO it doesn't bother if we re-export other utility type helpers. These helper types can be convenient for users to separate getters/actions/mutations to different files.

Makes sense. I've exposed them again.

blake-newman

As we are doing a large change for TS users, we should probably do this aswell: #994

So that $store can be argumented, thus giving more type safety.

lzgrzebski · 2018-05-14T08:04:04Z

any ETA when this will be released? Currently I have to patch my ts code with some explicit 'any' to make it work which isn't ideal.. :<

uoc1691 · 2018-06-01T08:21:28Z

Great Work! Question on the usage.
Can the helper be used like
storeHelper.mapMutations(["doSomething"]).doSomething({event: new MyCustomEvent()});

Without doing

methods: counterHelpers.mapMutations({ inc: 'increment' })

kirilvit · 2018-06-27T09:19:55Z

Please, resolve the conflicts

uoc1691 · 2018-06-28T00:59:40Z

Within an action "this" refers to the store instance. Can we modify DefineActions type like below?

type DefineActions<
    Actions,
    State,
    Getters,
    Mutations,
    ExtraActions = {},
    RootState = {},
    RootGetters = {},
    RootMutations = {},
    RootActions = {}
    > = {
      [K in keyof Actions]: (this: Store<RootState>,
        ctx: StrictActionContext<State, RootState, Getters, RootGetters, Mutations, RootMutations, Actions & ExtraActions, RootActions>,
        payload: Actions[K]
      ) => Promise<any> | void
    }

ffxsam · 2018-07-25T06:22:44Z

What's holding up this PR from being merged?

Can anyone tell me what a good workaround is, in the mean time? I'm not that fluent in TypeScript.

hobotroid · 2018-08-15T18:15:47Z

I too would love this PR to get merged.

RehanSaeed · 2018-08-31T16:02:07Z

Looks like @yyx990803 is yet to review this PR.

zhangbobell · 2018-09-02T09:00:27Z

It will make strong sense for this PR been merged.

latel · 2018-09-03T05:39:30Z

strill waiting for this pr

Raiondesu · 2018-09-24T08:52:06Z

Every maintainer of this repo seems to have forgotten about all type-improving pull requests...

ffxsam · 2018-10-22T17:25:52Z

@ktsn Any updates on this? I wrote a Vue + TS cookbook, and provide a workaround for this problem:

https://github.com/ffxsam/vue-typescript-cookbook#im-using-vuex-mapstate-or-mapgetters-and-typescript-is-saying-the-mapped-stategetters-dont-exist-on-this

But it would be nice if it worked properly out of the box.

ffxsam · 2018-11-13T16:39:00Z

Could someone please merge this? @yyx990803 @blake-newman @HerringtonDarkholme

kirilvit · 2018-11-14T10:27:57Z

Could someone please merge this? @yyx990803 @blake-newman @HerringtonDarkholme

I think this PR will not be ever merged, because TypeScript support with breaking changes is announced to be in VueJs 3 https://medium.com/the-vue-point/plans-for-the-next-iteration-of-vue-js-777ffea6fabf

ffxsam · 2018-11-14T14:03:27Z

@kirilvit That's a great point, I totally didn't think of that.

firewave-remo · 2018-11-16T06:33:48Z

But at least a statement would be fair, instead of just saying nothing...

exherb · 2018-12-05T23:36:10Z

any progress?

pikax · 2019-02-13T11:28:01Z

Made a PR ktsn#1 updating Typescript@3.3.3

joevandyk · 2019-02-14T03:38:29Z

Vue 3 is still a very long ways away, right? If the maintainer doesn't want to merge this, could they close it and explain why? Or suggest what changes need to be made to get this merged in?

pikax · 2019-02-14T08:49:41Z

I think this can't be merge because doesn't work on typescript 3.x (building errors)

ClickerMonkey · 2019-04-21T03:27:28Z

This is a little unrelated, but I've also create new typings for vuex. Similar to this, except instead of 4 interfaces to represent the state/getters/mutations/actions you specify one and it automatically can detect which properties are each:

https://github.com/ClickerMonkey/vuex-typescript-interface

kiaking · 2020-04-20T11:02:40Z

@ktsn Do you think this PR is still maintainable...? Or maybe we should close this one and start over if we really need it 😓

ktsn · 2020-04-20T11:43:17Z

We should go with Vuex 5's TypeScript improvement. Closing.

ktsn added 7 commits November 6, 2017 12:10

feat: improve helper types to utilize Vue 2.5 types

0768c80

feat(types): [WIP] more strict typed store assets

25775c5

Merge branch 'dev' into feat-improve-typing

21ee399

fix(types): relax map state function type

eee1f3c

test(types): update namespaced helper type test

f94cf70

feat(types): allow to specify assets types on mapXXX helpers

a5c4e26

chore(types): add comments for helpers and utilities types

58d28a5

ktsn requested review from yyx990803, HerringtonDarkholme and blake-newman January 4, 2018 16:39

This was referenced Jan 4, 2018

Use keyof to improve type inference in helpers #1105

Closed

Write Stores in Typescript #564

Open

HerringtonDarkholme reviewed Jan 6, 2018

View reviewed changes

fix(types): revert renaming Payload to avoid breaking change

0858c6d

Demivan suggested changes Jan 9, 2018

View reviewed changes

ktsn added 3 commits January 9, 2018 22:00

feat(helpers): return root helpers if no namespace is provided to cre…

1e27c5e

…ateNamespacedHelpers

feat(types): add DefineModule utility type

c2068f3

fix(types): allow to omit payload on mapped methods if it is untyped

7abf34f

HerringtonDarkholme reviewed Jan 10, 2018

View reviewed changes

blake-newman requested changes Jan 10, 2018

View reviewed changes

ktsn added 2 commits January 11, 2018 20:53

docs(helpers): improve createNamespacedHelpers description

9564b80

fix(types): expose DefineGetters/Mutations/Actions type

1aa407f

HerringtonDarkholme mentioned this pull request May 9, 2018

Better IntelliSense support for vuex vuejs/vetur#783

Closed

3 tasks

ktsn mentioned this pull request Jul 25, 2018

TypeScript type-checking bugs with mapState/mapGetters #1353

Closed

ktsn mentioned this pull request Sep 2, 2018

any progress about type safe of commit and dispatch ktsn/vuex-class#30

Closed

ktsn mentioned this pull request Oct 13, 2018

Discussion on removing mapXXX helpers in Vuex 4 #1417

Closed

EmmaLRussell mentioned this pull request Sep 3, 2019

mrc-443 Added uploadANC front end hivtools/hint#38

Merged

HIMISOCOOL mentioned this pull request Oct 29, 2019

mapActions: property does not exist on type ffxsam/vue-typescript-cookbook#2

Closed

ktsn closed this Apr 20, 2020

yoyo930021 mentioned this pull request Dec 26, 2020

Mutation not recognized when imported with mapMutations next to other methods vuejs/vetur#2592

Open


		Create namespaced component binding helpers. The returned object contains `mapState`, `mapGetters`, `mapActions` and `mapMutations` that are bound with the given namespace. [Details](modules.md#binding-helpers-with-namespace)

		If the namespace is not specified, it returns the root mapXXX helpers. This behavior is convenient to annotate strict types for mapXXX helpers.

feat: improve helper types for more type safety #1121

feat: improve helper types for more type safety #1121

Conversation

ktsn commented Jan 4, 2018 • edited Loading

Caveats

Store is still not typed

It does not infer the types completely if passing functions to mapXXX helpers.

Using root assets

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

HerringtonDarkholme commented Jan 6, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

HerringtonDarkholme Jan 6, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ktsn commented Jan 9, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Demivan Jan 9, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

HerringtonDarkholme Jan 10, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

blake-newman left a comment

Choose a reason for hiding this comment

lzgrzebski commented May 14, 2018 • edited Loading

uoc1691 commented Jun 1, 2018

kirilvit commented Jun 27, 2018

uoc1691 commented Jun 28, 2018 • edited Loading

ffxsam commented Jul 25, 2018

hobotroid commented Aug 15, 2018 • edited Loading

RehanSaeed commented Aug 31, 2018

zhangbobell commented Sep 2, 2018

latel commented Sep 3, 2018

Raiondesu commented Sep 24, 2018 • edited Loading

ffxsam commented Oct 22, 2018

ffxsam commented Nov 13, 2018

kirilvit commented Nov 14, 2018 • edited Loading

ffxsam commented Nov 14, 2018

firewave-remo commented Nov 16, 2018

exherb commented Dec 5, 2018

pikax commented Feb 13, 2019

joevandyk commented Feb 14, 2019

pikax commented Feb 14, 2019

ClickerMonkey commented Apr 21, 2019

kiaking commented Apr 20, 2020

ktsn commented Apr 20, 2020

ktsn commented Jan 4, 2018 •

edited

Loading

HerringtonDarkholme Jan 6, 2018 •

edited

Loading

Demivan Jan 9, 2018 •

edited

Loading

HerringtonDarkholme Jan 10, 2018 •

edited

Loading

lzgrzebski commented May 14, 2018 •

edited

Loading

uoc1691 commented Jun 28, 2018 •

edited

Loading

hobotroid commented Aug 15, 2018 •

edited

Loading

Raiondesu commented Sep 24, 2018 •

edited

Loading

kirilvit commented Nov 14, 2018 •

edited

Loading