Upgrade to Pro — share decks privately, control downloads, hide ads and more …

条件に応じた状態管理方法の選択

 条件に応じた状態管理方法の選択

North Ko-hi

December 11, 2019
Tweet

Other Decks in Programming

Transcript

  1. 自己紹介 - 名前:koheikitazawa (Twitter: きたざー) - 所属:SIer - 業務:PoC〜MVP開発とたまにAI開発 -

    Vuejs初めて5ヶ月!開発4ヶ月!初心者! https://www.npmjs.com/package/firex-store 作ったNPM: LT初心者です。 お願いします。
  2. アジェンダ - 経緯と目的 - 状態管理の方法  ~Vuex/Vue.observable/Simple Storeのメリット・デメリット~ - 状態管理の使い分け ~選定軸の一例~ -

    結論 - 作ったNPMライブラリの紹介 開発向け視点:コスト 保守向け視点:保守性・規約・デバッグ(TTD)・ 型推論
  3. Simple Store 保守性 規約レベル コスト デバッグ 型推論 低 低 低

    不可 可能 設定 (コーディング規約)を 決める必要あり JavaScript(TypeScr ipt)の知識のみで実 装が可能 store.stateを直接上 書きしてしまい、参照 渡しのデータの同一 性が消える可能性 store.stateを直接上 書きしてしまい、参照 渡しのデータの同一 性が消える可能性
  4. Vue.observable 保守性 規約レベル コスト デバッグ 型推論 中 低 低 不可

    可能 設定 (コーディング規約)を 決める必要あり JavaScript(TypeScr ipt)の知識のみで実 装が可能 store.stateを直接上 書きしてしまい、参照 渡しのデータの同一 性が消える可能性 実装次第でデータの 直接更新を不可能 にできるため
  5. Vuex 保守性 規約レベル コスト デバッグ 型推論 高 高 高 可能

    不可 (※デフォルト) 関心(責任)の分離 初心者でも同じよう なコードがかける 学習・実装コスト
  6. VuexとVue.observable/SimpleなStoreの使い分け Vue.observable/SimpleなStore 一度DBから取得後、参照のみで更新はしない?( Ex.システム定数) Vuex 更新した値により、複雑な分岐の発生無 & ( 更新元が単一 or

    複数だがアーキテクチャから特定可能 ) タイムトラベルデバックできなくてもいい? 小規模? 1. 更新しない→タイムトラベルデバッグの必要性 が限りなく少ないため 2. Vuexの場合、state/getter/action/mutation全て を実装する必要があり、実装コストが高いため
  7. VuexとVue.observable/SimpleなStoreの使い分け 一度DBから取得後、参照のみで更新はしない?( Ex.システム定数) Vue.observable/SimpleなStore Vuex 更新した値により、複雑な分岐の発生無 & ( 更新元が単一 or

    複数だがアーキテクチャから特定可能 ) タイムトラベルデバックできなくてもいい? 小規模? Ex. DBError管理用Store 更新元:各Repositoryの ErrorHandlerからのみ 描画:エラー内容 など 通常のデバッグでも事足りる
  8. VuexとVue.observable/SimpleなStoreの使い分け 一度DBから取得後、参照のみで更新はしない?( Ex.システム定数) 一度DBから取得後、参照のみで更新はしない?( Ex.システム定数) Vue.observable/SimpleなStore Vuex 更新した値により、複雑な分岐の発生無 & (

    更新元が単一 or 複数だがアーキテクチャから特定可能 ) タイムトラベルデバックできなくてもいい )? 小規模? アーキテクチャの理解& コードの質の統一が 設定レベルで可能なため ※人の増加・人の入れ替わ りが想定される場合はVuex の方がいい可能性
  9. 結論 要件/コーダの質などから適切な状態管理手法を選びましょう 保守性 規約レベル コスト デバッグ 型推論 Vuex 高 高

    高 可能 不可 (※デフォルト) Vue .observable 中 中 低 不可 可能 Simple Store 低 低 低 不可 可能