# Vuex とは

Vuex is a state management pattern + library for Vue.js applications. It serves as a centralized store for all the components in an application, with rules ensuring that the state can only be mutated in a predictable fashion. It also integrates with Vue's official devtools extension to provide advanced features such as zero-config time-travel debugging and state snapshot export / import.

Vuex は state(状態)管理のためのパターンであり、またそれを実装したライブラリで、Vue.js アプリケーションのために作られました。Vuex は、Vue.js アプリケーションのコンポーネントのための、中央集権的な store としての役割を果たします。(訳注: store とは state 管理の中心的役割を担う機構です) Vuex のルールに則ることで、予測可能な手続きによってのみ state が変更されることが保証されます。また、Vue が公式に提供する devtoool extension と連携することで、より高度な機能を使用することもできます。例えば設定なしで使用できる「time-travel debugging」や state のスナップショットをとって export / import する機能です。

### What is a "State Management Pattern" ?

State 管理の様式 (Pattern) とは

Let's start with a simple Vue counter app:

まずは簡単な Vue 製のカウンターアプリをみてみましょう。

```javascript
new Vue({
  // state
  data () {
    return {
      count: 0
    }
  },
  // view
  template: `
    <div>{{ count }}</div>
  `,
  // actions
  methods: {
    increment () {
      this.count++
    }
  }
})
```

このコードにはアプリケーションの以下の情報が含まれていますね。

* state: アプリケーションを駆動させていく源となる情報です。
* view: state をどのように画面に結びつけていくか、ということが書かれています。
* actions: view 層を通じた user からの操作に反応し、state を変更する方法が書かれています。

これらはまさに、"one-way data flow" というコンセプトがどのようなものであるのかを、簡潔に表してくれています。

しかし、この簡潔さは、複数のコンポーネントが同一の state を共有している場合、容易に破壊されてしまします。つまり次のような場合にです。

* 複数の view が、同一の state の一部分に依存している。
* 異なる view からの action が、同一の state の一部分を変更しなくてはいけない構造になっている。

第一の問題に関しては、props を渡していくことで解決することもできますが、しかしそうするとコンポーネントのネストが深い場合には、冗長になってしまいますし、また兄弟コンポーネントにおいてはこの手法は使うことができません。二つ目の問題に関しては、直接親や子のインスタンスを参照しようとしたり、もしくはイベントを介して、複数の state のコピーを同期的に変更しようとすることでしょう。しかしこのような手法は脆く、容易にメンテナンスが不可能がコードになることでしょう。

では、コンポーネントから共有している State を取り出して、それを Global Singleton で管理する手法をとるのはどうでしょうか。こうすることで、我々のコンポーネントのツリーは大きな "view" となり、そしてどのコンポーネントも state にアクセスすることができ、またどのコンポーネントも aciton をトリガーできるようになります。ツリーのどの位置にコンポーネントがあったとしてもです！

さらに、状態管理に関わる概念を定義、分離し、特定のルールを敷くことで、コードの構造と保守性を向上させることができます。

これが Vuex の背景にある基本的なアイディアであり、この考え方は Flux、 Redux そして The Elm Architecture から影響を受けたものです。これらと異なるのは、Vuex は Vue.js のために最適化された実装であり、それによって Vue の効率的に更新できる  granular reactivity system を最大限に活かすことができる点にあります。

### いつから Vuex を使うべきか

Vuex は共有される state の管理をよりうまくできるようにしてくれますが、一方で多くの概念を処理する必要がうまれ、そしてそのためにより多くのコードを書くことになります。これは、短期的生産性と長期的生産性のトレードオフです。

もしあなたが過去に大規模な SPA を構築した経験がない状態で Vuex に飛び込んで来られたとすれば、Vuex はおそらく冗長で面倒なものに思えるでしょう。それは全く自然な反応です。アプリケーションがシンプルな場合には、Vuex を使わないほうがいい場合が多いでしょう。Global event bus という手法を使えば十分だと思います。しかし中大規模な SPA をつくるのであれば、状態を Vue Component の外側に配置して運用していく良い方法について考えるちょうどいい時期でしょう。そして Vuex は自然な選択肢です。と Redux の作者である Dan Abramov も言っていました。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://super-yusuke.gitbook.io/udemy-vue-basic/vuex-de-state-wosuru/vuex-toha.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.