🎃

第7回 フロントエンドアーキテクチャを学ぶ

2021/11/23に公開約1,500字

読んだ記事

Vue Composition API を使ったストアパターンと TypeScript の組み合わせはどのくらいスケールするか?
compositon apiとストアのことを考えると寝れなくなるので、自分の中で咀嚼する意味も込めて読むことにした。

内容の自分的解釈

簡単に言えば、通常のcomposition api同様に状態管理に関わる部分を引き剥がしてストアとして取り扱うというもの。
簡単な例

import {reactive} from '@vue/compositon-api';

export default function testStore() {
  // 状態
  const state = reactive({
    text: string,
    status: number,
  });

  // 状態の取得関数(= getter)
  const getText = () => {
    return state.text;
  }

  const getStatus = () => {
    return state.status;
  }

  // 状態更新関数
  const updateText = (updatedText) => {
    state.text = updatedText;
  }

  const updateStatus = (updatedStatus) => {
    state.status = updatedStatus;
  }

  return {
    getText,
    getStatus,
    updateText,
    updateStatus,
  }
}

簡単な例としてはこのような形。また、provide/injectを使用することで親→子間でのstateの共通かを行う。また、グローバル変数に対しても、mainに対してprovideを行えば全てのページでinjectでき、実現が可能です(強引ですが、stateをストア関数の外側に定義をしても実現はできます)。
上記のようにVuexに近い形でstoreを定義すれば、Vuexを介さないストアパターンは実現できます。
が、このパターンではstore間に関連のあるパターン(e.g. ログイン状態が保持されている時にAPIをコールするなど)は対応しきれません。
ストア間の依存関係を扱うのであれば、現状はVuexの方が優れています。
が、provide/injectがあればprops/emitリレーは防ぐ、Vuexを使わないといったことは満たすことは可能です。

感想

Vuexより複雑でなくなるところが良いと思う反面、やはり自由度が高いのが面倒だと思った。
compostion apiを採用すrに当たってVuexを使わないで実装ができるというのはメリットと思う反面、ではデータの更新はどこまで許すか?そもそもローカルな状態を切り出しているだけだがそれでもstore(composable)で更新をするべきなのか?どこでstateはリアクティブにすべき?
などなど判断できる幅が大きすぎる印象がある。
結局以前のVuexを使うべきかと同じで、スコープやルールをはっきりとさせることが必要になるのが難しいと思った。
個人的に、自分はこのルールが良さそう、と思う方針を作れればと思った。

Discussion

ログインするとコメントできます