Help us understand the problem. What is going on with this article?

Vuexで状態管理の大事さを知る

More than 1 year has passed since last update.

こんな方へ最適な記事です

  • Vue.jsを絶賛勉強中の方
  • Vuex導入を推進する資料をお探しの方

いつ、Vuexを使うべきでしょうか?...今でしょ

やや古めの言い回しから始まりましたが気にせず使います。「今でしょ」
Vuex公式には控えめにこう書かれています。

もし、あなたが大規模な SPA を構築することなく、Vuex を導入した場合、冗長で恐ろしいと感じるかもしれません。そう感じることは全く普通です。あなたのアプリがシンプルであれば、Vuex なしで問題ないでしょう。

でも、おばちゃんはそうは思わないのです。シンプルなアプリは、永遠にシンプルなままでしょうか?
想像のナナメ上を行く追加要望、積み木崩し的機能変更、主担当の突然の失踪(話し反れ気味)...複雑さと規模がどんどん大きくなってしまうのが世の常ではないでしょうか?
実際、私はそういったシチュエーションに何度も遭遇しております。

「冗長」という言葉が大嫌いで、自他共に認める超面倒くさがり屋の私が、Vue.jsを導入(勉強)するなら、最初からVuexも導入(勉強)してほしいことをここに高々と宣言。
ゴリゴリにメンテされまくっているアプリに後から状態管理思想・概念を導入するって、影響調査とか考えるだけで白目になるのは私だけ...?
/* タイムリーな記事がトレンドに上がっていました。最初から考慮しておかないと後から痛い目見るものとしてテストもありますね */

Flux ライブラリは眼鏡のようなものです: それらが必要になったときに知るのです。

見えないと不平を言うよりも、すすんで眼鏡をかけましょう :angel:

...とは言っても、全ての状態をVuexの中に置かなくても良いんです

ひとつのコンポーネントだけに属している状態(=State)は、無理にVuexの中に置かなくても良いんです。不変のコンポーネントってどのくらい存在するのか?という議論は前述の話に戻ってしまいますが、なんでもかんでもVuexの中に置くという考えは改めたほうが良いかもですね。

Vuex公式より抜粋

Vuex を使うということは、全ての状態を Vuex の中に置くべき、というわけではありません。多くの状態を Vuex に置くことで、状態の変更がさらに明示的、デバッグ可能になりますが、ときにはコードを冗長でまわりくどいものにします。状態の一部がひとつのコンポーネントだけに属している場合は、それをローカルの状態として残しておくとよいでしょう。あなたは、トレードオフを考慮した上で、あなたのアプリの開発ニーズに合った決定をすべきです。

Vuexの状態管理概念を知って、正しく恐れる

物事において「正しく」恐れることはとても大事なことです。もしかしたらそれは、無知であるが故に(過剰に)恐れているだけかもしれません。不安を少しでも取り除く近道は、原理や思想、概念を知ることだと私は考えます。

では早速Vuexの概念を...といきたい所ですが、その前に、Vuexの“ルーツ”を先に知っておくとVuexへの理解が深まりそうな気がしますので、ルーツを分かりやすく説明しているサイトを集めてみました。Vuexのルーツは、FluxRedux、そしてThe Elm Architectureと言われています。

で、Vuexは?
Vuexアーキテクチャ
3つルーツから引き継ぐ特徴的な点
 1. 中心にあるものはストア(上図 緑の破線内)
 2. 状態(State)は信頼できる唯一の情報源 "single source of truth"
 3. 状態(State)を直接変更することはできず、変更する方法はMutationsからのcommitだけ

ルーツを辿ったあとだと、腹落ちもかなりスムーズでした。しかしひとつだけ素朴な疑問。
「なんでActionsとMutationsが2つ分かれているんだろう?」
公式ガイドにも書いてありますが忘れがちなので太字で書きます。
Actionsは非同期処理用、Mutationsは(状態を変更するという)同期処理用。
ふむ。確かに図でもActionsはBackend APIと結ばれていることから非同期処理を担っていることが分かりますね。非同期処理と同期処理を明示的に分けることのメリットはズバリ以下の引用が全てでしょう。

状態変更を非同期に組み合わせることは、プログラムの動きを予測することを非常に困難にします。例えば、状態を変更する非同期コールバックを持った 2つのメソッドを両方呼び出すとき、それらがいつ呼び出されたか、どちらが先に呼び出されたかを、どうやって知ればよいのでしょう?これがまさに、状態変更と非同期の 2つの概念を分離したいという理由です。Vuex では全てのミューテーションは同期的に行うという作法になっています:

ここまでまとめたところで、いよいよVuexの各機能について説明を、と思い、言葉よりも図解したほうが...と、独り悶々と構想を練っているうちに!すばらしい投稿が!あがってしまいましたおりましたので、リンクします。
- Vue.js + Vuexでデータが循環する全体像を図解してみた

最後に(感想)

今回は単なるリンク集になってしまい、餡子が少ないアンパンみたいになってしまいました。
けれど(世界に公開することがいいかは別として)こうして自分から外へ出すことは、自分の頭の中を整理できるのでそれはそれで良かったです。忘れっぽいし。
あと、Vuexの全体像図解の投稿がとっても分かりやすくて素敵なのですが、Gettersについての記載がないのがやや残念。おいおい追加で図解できたらいいなぁと思いました。

アプリケーション開発の基本として、家を建てるときのように、家族計画に沿って間取りやメンテしやすい設備にしておくことが大事...つまり最初が肝心で、無計画にごちゃごちゃと作るのではなく、「シンプル・イズ・ベスト」を意識して構築することが大事なんだと再認識しました。
そのシンプルさを維持するにはルール(概念)を制定し、それを守ること。
そして、プログラミングにおいてルールを守る目的は、コードの構造と保守性を向上させるため、ですよね。

Simplicity is prerequisite for reliability.
- Edsger Wybe Dijkstra

単純であることは信頼性が前提条件です。
- エドガー・ダイクストラ (オランダ人の計算機科学者。構造化プログラミングの提唱者。)

最後に、たくさんの参考サイトに感謝いたします。
追記:Vuexは「ビューックス」っと読むのが主流らしい。

terraphic
フロンドエンドがメインですがバックエンドもろもろもこなしてます
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away