Vuexの型定義を覗いてみる〜その1〜
TypeScriptでVuexを用いた開発を行っていくと、ジェネリクスを駆使してstateなどの型情報を付与していくことになります。サンプルコードなどを参考に実装していくと、こうすればいいんだろうなという表面上の解は得られるのですが、どうしてそうしなければならないのかイマイチよくわからないまま実装していくことがしばしばあります。stateなどの補完がされることは確認できるのですが、どうしてできるのかちょっと疑問に思いました。
よくわからないまま実装するのも良くないので、今回はVuexでStoreを実装していくときにTypeScriptでどう型情報が付与されていくのかを見ていきたいと思います。
今回の調査のためのサンプルコードはこちらになります。
すべてのはじまり new Vuex.Store<RootState>()
まずStoreを作成するため new Vuex.Store<RootState>()
を実行します。
// 細かい部分は省略しています
import Form, { FormState } from "./Form";
import List, { ListState } from "./List";
export interface MyRootState {
Form: FormState;
List: ListState;
}
const store = new Vuex.Store<MyRootState>({
modules: {
Form,
List
}
});
Form
と List
のStoreをimportしてモジュールにセットしています。FormState
と ListState
はStateの型情報で、次のように定義されています。
export type FormState = {
text: string;
};
type Todo = {
text: string;
};
export type ListState = {
todoList: Todo[];
};
FormState
と ListState
をもつ MyRootState
を定義し、 new Vuex.Store<MyRootState>()
のようにセットすることでstateの補完が効くようになります。
ここで型情報をセットすることでVSCodeなどで補完が効くことが確認できます。
MyRootState
をセットしないと補完が効かないことも確認できます。
(どうでもいい話ですがジェネリクスで型情報をセットするときの正しい言葉の使い方がわかりません。ジェネリクスとして○○をセットする?)
セットされたMyRootStateがどのように働くのか
MyRootState
をセットすることで型情報が付与され補完が効くことが確認できました。次にどうして補完が効くようになるのか見ていきたいと思います。
まず Vuex.Store
の型がどのように実装されているのかを見てみます。
export declare class Store<S> {
constructor(options: StoreOptions<S>);
readonly state: S;
readonly getters: any;
// 以下省略
}
Store
で入力される型情報 S
、つまり今回わたしている MyRootState
はコンストラクタで使用されている StoreOption
や readonly State
などで使われていることがわかります。
readonly state: S;
でStoreから参照できるstateに型情報が付与され、補完が効くようになっているようです。
ちなみに readonly
とは何なのでしょうか?
TypeScriptの readonly
とは任意のプロパティを読み取り専用にするためにマークできる機能で、マークしたプロパティを上書きしようとするとコンパイルエラーにしてくれます。
簡単に見ていきましたが、storeから Form
や List
のStateが補完されるのは Store
の型定義で state
のプロパティに入力された MyRootState
の型情報をわたしているからのようです。意外とあっさりと答えにたどり着きました。
Modulesに不正なModuleが登録されない仕組み
流石にstateの型補完だけだと内容があまりにも足りないのでmodulesでわたしているmoduleで不正なmoduleが渡らないように型で守る仕組みについて見ていきます。
ますmoduleはStoreの引数のオブジェクトにして渡されます。Storeの引数として渡されるオブジェクトは StoreOptions
という型に沿ったオブジェクトとして渡す必要があります。StoreOptions
の型情報は次のようになります。
export interface StoreOptions<S> {
state?: S | (() => S);
getters?: GetterTree<S, S>;
actions?: ActionTree<S, S>;
mutations?: MutationTree<S>;
modules?: ModuleTree<S>;
plugins?: Plugin<S>[];
strict?: boolean;
}
それぞれのプロパティに?
がついています。?
のついてプロパティは省略可能なプロパティです。今回のサンプルコードでは modules
しか入れていませんでした。その他は ?
がついているので省略可能だったわけです。
逆にここで列挙されていないプロパティを追加しようとしてもコンパイルエラーになります。
hogeというプロパティを追加しようとしてもエラーになることがわかります。
ModuleTree
の型定義は次のようになります。
export interface ModuleTree<R> {
[key: string]: Module<any, R>;
}
ModuleTree
の中身はキーとそれに対応する Module
の型定義となっています。
なので Module
を実装していない値を登録しようとするとコンパイルエラーになります。
test
というプロパティに number型の1をセットするとコンパイルエラーになります。
次にModule
の型定義を見ていきます。
export interface Module<S, R> {
namespaced?: boolean;
state?: S | (() => S);
getters?: GetterTree<S, R>;
actions?: ActionTree<S, R>;
mutations?: MutationTree<S>;
modules?: ModuleTree<R>;
}
Module
は
- namespaced
- state
- getters
- actions
- mutations
- modules
のプロパティを持ちます。 それぞれのプロパティによって入る型の定義が違うので、例えばactionsプロパティに期待しない型が入るとコンパイルエラーになります。
const Sample = {
actions: []
}
const store = new Vuex.Store<MyRootState>({
plugins: [createLogger({})],
modules: {
Form,
List,
Sample //actionsはActionTreeを実装していないのでコンパイルエラーになる。
},
});
VuexはTypeScriptで作られているわけではないので、素のJavaScriptのままだと不正なモジュールが登録されてもコンパイル時にわからずランタイムエラーになるのですが、型定義ファイルが定義されTypeScriptで書けるようになると、不正な値はコンパイルエラーで事前にわかるのでだいぶ開発しやすくなります。
dispatch
や commit
時にはまだ課題があるのですがTypeScriptで書いて少なくともマイナスになることはないと思います。
まとめ
以上。Vuexの型定義について見ていきました。記事を書くためにVuexの型定義ファイルを眺めていたのですが、型をあとづけするのはかなり大変そうでした。 ActionTree
や ActionHandler
あたりはかなりの苦労が伺えます。
型定義を眺めているとTypeScriptの勉強になるので、Vuex周りの型定義については引き続き眺めていこうと思います。
Author And Source
この問題について(Vuexの型定義を覗いてみる〜その1〜), 我々は、より多くの情報をここで見つけました https://qiita.com/nasum/items/7392365f4d3835e9d054著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .