Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
頑張らないオレオレVuex規約を作った話
Search
is_ryo
January 15, 2020
Programming
4
2.7k
頑張らないオレオレVuex規約を作った話
is_ryo
January 15, 2020
Tweet
Share
More Decks by is_ryo
See All by is_ryo
Unknownのことをちゃんと知りたい_関西フロントエンド忘年会
[email protected]
× KINTOテクノロジーズ
is_ryo
0
13
tRPC入門
is_ryo
1
220
TypeScriptでWebAssemblyに入門しよう
is_ryo
0
230
Honoが良さそう🔥
is_ryo
1
1k
LambdaのNodejsをアップデートしたら困った話
is_ryo
2
1.3k
AppSyncで始めるGraphQL
is_ryo
1
600
Other Decks in Programming
See All in Programming
PHPカンファレンス名古屋2025 タスク分解の試行錯誤〜レビュー負荷を下げるために〜
soichi
1
680
CDK開発におけるコーディング規約の運用
yamanashi_ren01
2
250
Ça bouge du côté des animations CSS !
goetter
2
150
Datadog DBMでなにができる? JDDUG Meetup#7
nealle
0
150
PHPのバージョンアップ時にも役立ったAST
matsuo_atsushi
0
230
1年目の私に伝えたい!テストコードを怖がらなくなるためのヒント/Tips for not being afraid of test code
push_gawa
1
610
データベースのオペレーターであるCloudNativePGがStatefulSetを使わない理由に迫る
nnaka2992
0
230
AIプログラミング雑キャッチアップ
yuheinakasaka
18
4.4k
PRレビューのお供にDanger
stoticdev
1
230
複数のAWSアカウントから横断で 利用する Lambda Authorizer の作り方
tc3jp
0
120
Boost Performance and Developer Productivity with Jakarta EE 11
ivargrimstad
0
830
ABEMA iOS 大規模プロジェクトにおける段階的な技術刷新 / ABEMA iOS Technology Upgrade
akkyie
1
110
Featured
See All Featured
Visualization
eitanlees
146
15k
The Language of Interfaces
destraynor
156
24k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
Why You Should Never Use an ORM
jnunemaker
PRO
55
9.2k
The World Runs on Bad Software
bkeepers
PRO
67
11k
Optimizing for Happiness
mojombo
376
70k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.7k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Speed Design
sergeychernyshev
27
810
BBQ
matthewcrist
87
9.5k
Practical Orchestrator
shlominoach
186
10k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
Transcript
頑張らないオレオレVuex規約を 作った話 2020/01/15 v-kansai#13 Ryosuke Izumi
Ryosuke Izumi WebApplication / IoT AWS / Vue / TypeScript
/ Serverless v-kansai organizer @is_ryo
Vue 使ってますか?
Vuexって使ってますか?
Vuexってめちゃくちゃ便利ですよね
そう便利…なんだけど……
Vuexの治安悪くなりがち
• 巨大化する State… • 直接呼ばれるmutation… • getters?actions?なにそれおいしいの? • modulesが分けられてない… •
とりあえず Vuex に突っ込んでおくかーみ たいな風潮 • ゴミ箱と化すStore • etc...
None
そうだ。規約を作ろう。
下記3点を解決できるような、かつあんまり頑張 らない規約を作った • Storeの中身を整理したい • 整理した上でComponentがどのStoreを使って いるのかわかりやすくしたい • Storeに Store.hoge
でアクセスしたくない
stores/ 以下にVuex関係の ソースを置く
ディレクトリ構成はこんな感じ src/stores/ ├── module.ts ├── module_2.ts ├── store.ts └── types.d.ts
modulesを切って、それぞ れのModuleファイルを生成 する
Moduleの構成要素は、 namespaced / state / mutations / actions (/ getters)
store.ts
flags.ts(moduleファイル(一部抜粋))
直接 mutations を使わない
• 直接 Store.commit("hoge") って書きたくない • actions 経由で mutations を使う •
Store.dispatch("hogehoge") って書いていく
なぜ action 経由で mutaiton を呼び出すのか? Vuex のドキュメントには「Vuex では全ての mutationは同期的に行うという作法になってい ます」と書いてあって「actionの中では非同期の
操作を行うことができる」となっているので、基 本的に action を経由するようにしている
createNamespacedHelpers を使って、Storeとやり取り する
• というかそもそも Store.hoge って書きたくな い… • あと import Store from
"@/stores/store" と も書きたくない… • せっかく namespace 切ったんだから NamespacedHelpers を使う
None
None
None
まとめ
• NamespacedHelpers 便利 • 治安を守るためにはちゃんと規約を作ろう • といっても必要となる規約はどこも違うだろう から参考程度になれば嬉しい
おわり