🎃

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

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

読んだ記事

Vuex はなるべく避ける
この記事を読むに至った背景としては、composition apiを使ったアーキテクチャを考えるのに、一度Vuexを再度自分の中で咀嚼したいと思ったから(そもそもストアパターンって意味があるのだっけ、というところ)。

内容の自分的解釈

Vuexは「グローバル変数(state)」を取り回すために使う。
action/mutations/getterを使用してstateの更新/取得などを行う。
よくやりがちなのが、「なんでもstore」に入れてしまうというもの。
そもそもグローバル変数を複数持つこと自体が良くない(グローバル変数はどこからでも変更できてしまうため)ので、上記の「なんでもstore」という考え方は良くない。
が、グローバル定数とすべきものも発生します(e.g. ログイン情報など)。
これらはVuexに入るべきなので、どのような変数についてはVuexを使用するかというスコープを置けば正しく運用できると思われます。
(結局ここの"スコープ"というところが一番難しいわけですが、、、)

感想

記事の終盤に記載のあった「JSON色付け係」というところについて、ちょっと気になったので記載。
個人的にもFEはできるだけシンプルであるべきだと思っている。
理由としてはAPI側の出力機能としての側面がFEについては大きいと思っていて、表現面(UI)での複雑性はあれど、ビジネスロジックについてはFEが担保する範囲はそれほどおおきくないと思っているためである。
が、この「シンプルであるべき」がやはり難しいところで、それが今回読んだ記事の「Vuex はなるべく避ける」という話題になると思う。
Vuexは1グローバル変数を更新するために非常に段階的な手続きを踏む。
ここは人によってはシンプルでないとも取れ、使うべきではないとなると思う。が、解釈で記載をした通り、グローバル定数とすべき値もあるはずなので、簡単に切り捨てる、とはできない。
Vuexを含めたシンプルな実装を求めると、そのためのスコープを引くこととなるが、スコープを引くくらいならそもそも全てグローバルオブジェクトにしてしまってシンプルさは担保されるのでは?などとなって、結局ぐるぐると回るわけである。
実装などが始まる前、コーディングやアークテクチャをしっかりと考えることの重要さがよくわかったと思った。

Discussion

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