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
条件に応じた状態管理方法の選択
Search
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
North Ko-hi
December 11, 2019
Programming
0
1.2k
条件に応じた状態管理方法の選択
North Ko-hi
December 11, 2019
Tweet
Share
Other Decks in Programming
See All in Programming
AI時代のキャリアプラン「技術の引力」からの脱出と「問い」へのいざない / tech-gravity
minodriven
21
7.4k
humanlayerのブログから学ぶ、良いCLAUDE.mdの書き方
tsukamoto1783
0
200
Lambda のコードストレージ容量に気をつけましょう
tattwan718
0
150
なるべく楽してバックエンドに型をつけたい!(楽とは言ってない)
hibiki_cube
0
140
Honoを使ったリモートMCPサーバでAIツールとの連携を加速させる!
tosuri13
1
180
AIによるイベントストーミング図からのコード生成 / AI-powered code generation from Event Storming diagrams
nrslib
2
1.9k
コントリビューターによるDenoのすゝめ / Deno Recommendations by a Contributor
petamoriken
0
210
AI時代の認知負荷との向き合い方
optfit
0
170
高速開発のためのコード整理術
sutetotanuki
1
410
MUSUBIXとは
nahisaho
0
140
CSC307 Lecture 03
javiergs
PRO
1
490
Apache Iceberg V3 and migration to V3
tomtanaka
0
180
Featured
See All Featured
The World Runs on Bad Software
bkeepers
PRO
72
12k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
47
7.9k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
760
The State of eCommerce SEO: How to Win in Today's Products SERPs - #SEOweek
aleyda
2
9.6k
Navigating Team Friction
lara
192
16k
The Director’s Chair: Orchestrating AI for Truly Effective Learning
tmiket
1
100
Why You Should Never Use an ORM
jnunemaker
PRO
61
9.7k
Digital Ethics as a Driver of Design Innovation
axbom
PRO
1
190
sira's awesome portfolio website redesign presentation
elsirapls
0
150
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
287
14k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.4k
Believing is Seeing
oripsolob
1
59
Transcript
条件に応じた 状態管理方法の選択 きたざー
自己紹介 - 名前:koheikitazawa (Twitter: きたざー) - 所属:SIer - 業務:PoC〜MVP開発とたまにAI開発 -
Vuejs初めて5ヶ月!開発4ヶ月!初心者! https://www.npmjs.com/package/firex-store 作ったNPM: LT初心者です。 お願いします。
※ あくまで数ある考えの中の1つであり、 この考えが唯一神、 という訳ではありません。
アジェンダ - 経緯 - 状態管理の方法 ~Vuex/Vue.observable/Simple Storeのメリット・デメリット~ - 状態管理の使い分け ~選定軸の一例~ -
結論 - 作ったNPMライブラリの紹介
Event Bus Vuex Simple Store Vue.observable
Event Bus Vuex Simple Store Vue.observable
アジェンダ - 経緯と目的 - 状態管理の方法 ~Vuex/Vue.observable/Simple Storeのメリット・デメリット~ - 状態管理の使い分け ~選定軸の一例~ -
結論 - 作ったNPMライブラリの紹介
言語定義 保守性 ・テスタビリティ 大規模(開発) ・開発人員が8人以上
アジェンダ - 経緯と目的 - 状態管理の方法 ~Vuex/Vue.observable/Simple Storeのメリット・デメリット~ - 状態管理の使い分け ~選定軸の一例~ -
結論 - 作ったNPMライブラリの紹介 開発向け視点:コスト 保守向け視点:保守性・規約・デバッグ(TTD)・ 型推論
Simple Store
Simple Store 保守性 規約レベル コスト デバッグ 型推論 低 低 低
不可 可能 設定 (コーディング規約)を 決める必要あり JavaScript(TypeScr ipt)の知識のみで実 装が可能 store.stateを直接上 書きしてしまい、参照 渡しのデータの同一 性が消える可能性 store.stateを直接上 書きしてしまい、参照 渡しのデータの同一 性が消える可能性
Vue.observable
Vue.observable 保守性 規約レベル コスト デバッグ 型推論 中 低 低 不可
可能 設定 (コーディング規約)を 決める必要あり JavaScript(TypeScr ipt)の知識のみで実 装が可能 store.stateを直接上 書きしてしまい、参照 渡しのデータの同一 性が消える可能性 実装次第でデータの 直接更新を不可能 にできるため
Vuex
Vuex 保守性 規約レベル コスト デバッグ 型推論 高 高 高 可能
不可 (※デフォルト) 関心(責任)の分離 初心者でも同じよう なコードがかける 学習・実装コスト
アジェンダ - 経緯と目的 - 状態管理の方法 ~Vuex/Vue.observable/Simple Storeのメリット・デメリット~ - 状態管理の使い分け ~選定軸の一例~ -
結論 - 作ったNPMライブラリの紹介
VuexとVue.observable/SimpleなStoreの使い分け Vue.observable/SimpleなStore 一度DBから取得後、参照のみで更新はしない?( Ex.システム定数) Vuex 更新した値により、複雑な分岐の発生無 & ( 更新元が単一 or
複数だがアーキテクチャから特定可能 ) タイムトラベルデバックできなくてもいい? 小規模?
VuexとVue.observable/SimpleなStoreの使い分け Vue.observable/SimpleなStore 一度DBから取得後、参照のみで更新はしない?( Ex.システム定数) Vuex 更新した値により、複雑な分岐の発生無 & ( 更新元が単一 or
複数だがアーキテクチャから特定可能 ) タイムトラベルデバックできなくてもいい? 小規模?
VuexとVue.observable/SimpleなStoreの使い分け Vue.observable/SimpleなStore 一度DBから取得後、参照のみで更新はしない?( Ex.システム定数) Vuex 更新した値により、複雑な分岐の発生無 & ( 更新元が単一 or
複数だがアーキテクチャから特定可能 ) タイムトラベルデバックできなくてもいい? 小規模? 1. 更新しない→タイムトラベルデバッグの必要性 が限りなく少ないため 2. Vuexの場合、state/getter/action/mutation全て を実装する必要があり、実装コストが高いため
VuexとVue.observable/SimpleなStoreの使い分け 一度DBから取得後、参照のみで更新はしない?( Ex.システム定数) Vue.observable/SimpleなStore Vuex 更新した値により、複雑な分岐の発生無 & ( 更新元が単一 or
複数だがアーキテクチャから特定可能 ) タイムトラベルデバックできなくてもいい? 小規模? そのまんま
VuexとVue.observable/SimpleなStoreの使い分け 一度DBから取得後、参照のみで更新はしない?( Ex.システム定数) Vue.observable/SimpleなStore Vuex 更新した値により、複雑な分岐の発生無 & ( 更新元が単一 or
複数だがアーキテクチャから特定可能 ) タイムトラベルデバックできなくてもいい? 小規模? Ex. DBError管理用Store 更新元:各Repositoryの ErrorHandlerからのみ 描画:エラー内容 など 通常のデバッグでも事足りる
VuexとVue.observable/SimpleなStoreの使い分け 一度DBから取得後、参照のみで更新はしない?( Ex.システム定数) 一度DBから取得後、参照のみで更新はしない?( Ex.システム定数) Vue.observable/SimpleなStore Vuex 更新した値により、複雑な分岐の発生無 & (
更新元が単一 or 複数だがアーキテクチャから特定可能 ) タイムトラベルデバックできなくてもいい )? 小規模? アーキテクチャの理解& コードの質の統一が 設定レベルで可能なため ※人の増加・人の入れ替わ りが想定される場合はVuex の方がいい可能性
※ もちろんこれだけではない
開発にアサインされる 人員のスキルセットは? 開発したサービスは 何年間使うのか? PoCか、製品か サービスを保守するのは 誰か? 外部委託か?
結論 要件/コーダの質などから適切な状態管理手法を選びましょう 保守性 規約レベル コスト デバッグ 型推論 Vuex 高 高
高 可能 不可 (※デフォルト) Vue .observable 中 中 低 不可 可能 Simple Store 低 低 低 不可 可能
終了前に... https://www.npmjs.com/package/firex-store https://github.com/nor-ko-hi-jp/firex-store 何故、車輪の再開発をしたか知りたければ説明しますので、 気軽にお話しかけください。 基本はVuexFireと同じ 機能と思ってください。
以上 ご静聴ありがとうございました!