docs: fix heading level (#2074)

Author: Alanscut

docs/guide/testing.md

@@ -4,7 +4,7 @@
 
 The main parts we want to unit test in Vuex are mutations and actions.
 
-### Testing Mutations
+## Testing Mutations
 
 Mutations are very straightforward to test, because they are just functions that completely rely on their arguments. One trick is that if you are using ES2015 modules and put your mutations inside your `store.js` file, in addition to the default export, you should also export the mutations as a named export:
 
@@ -49,7 +49,7 @@ describe('mutations', () => {
 })
 ```
 
-### Testing Actions
+## Testing Actions
 
 Actions can be a bit more tricky because they may call out to external APIs. When testing actions, we usually need to do some level of mocking - for example, we can abstract the API calls into a service and mock that service inside our tests. In order to easily mock dependencies, we can use webpack and [inject-loader](https://github.com/plasticine/inject-loader) to bundle our test files.
 
@@ -146,7 +146,7 @@ describe('actions', () => {
 })
 ```
 
-### Testing Getters
+## Testing Getters
 
 If your getters have complicated computation, it is worth testing them. Getters are also very straightforward to test for the same reason as mutations.
 
@@ -193,11 +193,11 @@ describe('getters', () => {
 })
 ```
 
-### Running Tests
+## Running Tests
 
 If your mutations and actions are written properly, the tests should have no direct dependency on Browser APIs after proper mocking. Thus you can simply bundle the tests with webpack and run it directly in Node. Alternatively, you can use `mocha-loader` or Karma + `karma-webpack` to run the tests in real browsers.
 
-#### Running in Node
+### Running in Node
 
 Create the following webpack config (together with proper [`.babelrc`](https://babeljs.io/docs/usage/babelrc/)):
 
@@ -228,13 +228,13 @@ webpack
 mocha test-bundle.js
 ```
 
-#### Running in Browser
+### Running in Browser
 
 1. Install `mocha-loader`.
 2. Change the `entry` from the webpack config above to `'mocha-loader!babel-loader!./test.js'`.
 3. Start `webpack-dev-server` using the config.
 4. Go to `localhost:8080/webpack-dev-server/test-bundle`.
 
-#### Running in Browser with Karma + karma-webpack
+### Running in Browser with Karma + karma-webpack
 
 Consult the setup in [vue-loader documentation](https://vue-loader.vuejs.org/en/workflow/testing.html).

docs/ja/README.md

@@ -6,7 +6,7 @@ Vuex は Vue.js アプリケーションのための **状態管理パターン
 これは予測可能な方法によってのみ状態の変異を行うというルールを保証し、アプリケーション内の全てのコンポーネントのための集中型のストアとして機能します。
 また Vue 公式の[開発ツール拡張](https://github.com/vuejs/vue-devtools)と連携し、設定なしでタイムトラベルデバッグやステートのスナップショットのエクスポートやインポートのような高度な機能を提供します。
 
-### "状態管理パターン"とはなんですか？
+## "状態管理パターン"とはなんですか？
 
 単純な Vue で作られたカウンターアプリをみてみましょう:
 
@@ -61,7 +61,7 @@ new Vue({
 
 ![vuex](/vuex.png)
 
-### いつ、Vuexを使うべきでしょうか？
+## いつ、Vuexを使うべきでしょうか？
 
 Vuex は、共有状態の管理に役立ちますが、さらに概念やボイラープレートのコストがかかります。これは、短期的生産性と長期的生産性のトレードオフです。
 

docs/ja/guide/README.md

@@ -8,7 +8,7 @@ Vuex アプリケーションの中心にあるものは**ストア**です。"
 
 2. ストアの状態を直接変更することはできません。明示的に**ミューテーションをコミットする**ことによってのみ、ストアの状態を変更します。これによって、全ての状態の変更について追跡可能な記録を残すことが保証され、ツールでのアプリケーションの動作の理解を助けます。
 
-### シンプルなストア
+## シンプルなストア
 
 :::tip 注意
 私たちは、このドキュメントのコード例に ES2015 のシンタックスを利用しています。 もし触れたことがなければ、[ぜひ触れてください](https://babeljs.io/docs/learn-es2015/)！

docs/ja/guide/actions.md

@@ -39,7 +39,7 @@ actions: {
 }
 ```
 
-### アクションのディスパッチ
+## アクションのディスパッチ
 
 アクションは `store.dispatch` がトリガーとなって実行されます:
 
@@ -97,7 +97,7 @@ actions: {
 
 一連の非同期の処理を実行しつつ、ミューテーションのコミットによってのみ副作用（状態の変更）を与えていることに注意してください。
 
-### コンポーネント内でのアクションのディスパッチ
+## コンポーネント内でのアクションのディスパッチ
 
 `this.$store.dispatch('xxx')` でコンポーネント内でアクションをディスパッチできます。あるいはコンポーネントのメソッドを `store.dispatch` にマッピングする `mapActions` ヘルパーを使うこともできます（ルートの `store` の注入が必要です）:
 
@@ -119,7 +119,7 @@ export default {
 }
 ```
 
-### アクションを構成する
+## アクションを構成する
 
 アクションはしばしば非同期処理を行いますが、アクションが完了したことをどうやって知れば良いのでしょう？そしてもっと重要なことは、さらに複雑な非同期処理を取り扱うために、どうやって複数のアクションを構成させるかということです。
 

docs/ja/guide/forms.md

@@ -40,7 +40,7 @@ mutations: {
 }
 ```
 
-### 双方向算出プロパティ
+## 双方向算出プロパティ
 
 確かに、上記の例は単純な `v-model` と ローカルステートよりもかなり冗長で、`v-model` のいくつかの有用な機能が使えません。代わりに、セッターで双方向算出プロパティを使うアプローチがあります。
 

docs/ja/guide/getters.md

@@ -34,7 +34,7 @@ const store = new Vuex.Store({
 })
 ```
 
-### プロパティスタイルアクセス
+## プロパティスタイルアクセス
 
 ゲッターは `store.getters` オブジェクトから取り出され、プロパティとしてアクセスすることができます:
 
@@ -69,7 +69,7 @@ computed: {
 
 プロパティとしてアクセスされるゲッターは Vue のリアクティブシステムの一部としてキャッシュされるという点に留意してください。
 
-### メソッドスタイルアクセス
+## メソッドスタイルアクセス
 
 関数を返り値にすることで、ゲッターに引数を渡すこともできます。これは特にストアの中の配列を検索する時に役立ちます：
 ```js
@@ -87,7 +87,7 @@ store.getters.getTodoById(2) // -> { id: 2, text: '...', done: false }
 
 メソッドによってアクセスされるゲッターは呼び出す度に実行され、その結果はキャッシュされない点に留意してください。
 
-### `mapGetters` ヘルパー
+## `mapGetters` ヘルパー
 
 `mapGetters` ヘルパーはストアのゲッターをローカルの算出プロパティにマッピングさせます:
 

docs/ja/guide/modules.md

@@ -31,7 +31,7 @@ store.state.a // -> `moduleA` のステート
 store.state.b // -> `moduleB` のステート
 ```
 
-### モジュールのローカルステート
+## モジュールのローカルステート
 
 モジュールのミューテーションやゲッターの中では、渡される第1引数は**モジュールのローカルステート**です。
 
@@ -83,7 +83,7 @@ const moduleA = {
 }
 ```
 
-### 名前空間
+## 名前空間
 
 デフォルトでは、モジュール内部のアクション、ミューテーション、そしてゲッターは**グローバル名前空間**の元で登録されます - これにより、複数のモジュールが同じミューテーション/アクションタイプに反応することができます。
 
@@ -134,7 +134,7 @@ const store = new Vuex.Store({
 
 名前空間のゲッターとアクションは、ローカライズされた `getters`、`dispatch`、`commit` を受け取ります。言い換えれば、同じモジュールに接頭辞 (prefix) を書き込まずに、モジュールアセットを使用することができます。名前空間オプションの切り替えは、モジュール内のコードには影響しません。
 
-#### 名前空間付きモジュールでのグローバルアセットへのアクセス
+### 名前空間付きモジュールでのグローバルアセットへのアクセス
 
 グローバルステートとゲッターを使いたい場合、`rootState` と `rootGetters` はゲッター関数の第3引数と第4引数として渡され、アクション関数に渡される `context` オブジェクトのプロパティとしても公開されます。
 
@@ -174,7 +174,7 @@ modules: {
 }
 ```
 
-#### 名前空間付きモジュールでのグローバルアクションへの登録
+### 名前空間付きモジュールでのグローバルアクションへの登録
 
 名前空間付きモジュールでグローバルアクションに登録したい場合、`root: true` でそれをマークでき、そしてアクション定義を `handler` 関数に置くことができます。例えば:
 
@@ -200,7 +200,7 @@ modules: {
 ```
 
 
-#### 名前空間によるバインディングヘルパー
+### 名前空間によるバインディングヘルパー
 
 `mapState`、`mapGetters`、`mapActions`、そして `mapMutations` ヘルパーを使って名前空間付きモジュールをコンポーネントにバインディングするとき、少し冗長になります:
 
@@ -261,7 +261,7 @@ export default {
 }
 ```
 
-#### プラグイン開発者向けの注意事項
+### プラグイン開発者向けの注意事項
 
 モジュールを提供する[プラグイン](plugins.md)を作成し、ユーザーがそれらを Vuex ストアに追加できるようにすると、モジュールの予測できない名前空間が気になるかもしれません。あなたのモジュールは、プラグインユーザーが名前空間付きモジュールの元にモジュールを追加すると、その名前空間に属するようになります。この状況に適応するには、プラグインオプションを使用して名前空間の値を受け取る必要があります。
 
@@ -277,7 +277,7 @@ export function createPlugin (options = {}) {
 }
 ```
 
-### 動的にモジュールを登録する
+## 動的にモジュールを登録する
 
 ストアが作られた**後**に `store.registerModule` メソッドを使って、モジュールを登録できます:
 
@@ -301,13 +301,13 @@ store.registerModule(['nested', 'myModule'], {
 
 また、すでにモジュールが登録されているかどうかを `store.hasModule(moduleName)` メソッドを使って確認することができます。
 
-#### ステートの保持
+### ステートの保持
 
 サーバサイドレンダリングされたアプリケーションから状態を保持するなど、新しいモジュールを登録するときに、以前の状態を保持したい場合があります。`preserveState` オプション（`store.registerModule('a', module, { preserveState: true })`）でこれを実現できます。
 
 `preserveState: true` を設定した場合、モジュールを登録する際に、アクション、ミューテーション、そしてゲッターは追加されますがステートは追加されません。これはストアのステートはすでにモジュールのステートを登録しているので、それを上書きしないようにするためです。
 
-### モジュールの再利用
+## モジュールの再利用
 
 時どき、モジュールの複数インスタンスを作成する必要があるかもしれません。例えば:
 

docs/ja/guide/mutations.md

@@ -24,7 +24,7 @@ const store = new Vuex.Store({
 store.commit('increment')
 ```
 
-### 追加の引数を渡してコミットする
+## 追加の引数を渡してコミットする
 
 `store.commit` に追加の引数を渡すこともできます。この追加の引数は、特定のミューテーションに対する**ペイロード**と呼びます:
 
@@ -58,7 +58,7 @@ store.commit('increment', {
 })
 ```
 
-### オブジェクトスタイルのコミット
+## オブジェクトスタイルのコミット
 
 また `type` プロパティを持つオブジェクトを使って、ミューテーションをコミットすることもできます:
 
@@ -80,7 +80,7 @@ mutations: {
 ```
 
 
-### Vue のリアクティブなルールに則ったミューテーション
+## Vue のリアクティブなルールに則ったミューテーション
 
 Vuex ストアの状態は Vue によってリアクティブになっているので、状態を変更すると、状態を監視している Vue コンポーネントは自動的に更新されます。これは Vuex のミューテーションは、通常の Vue と動作させているときと同じく、リアクティブな値に関する注意が必要であることを意味します:
 
@@ -96,7 +96,7 @@ Vuex ストアの状態は Vue によってリアクティブになっている
     state.obj = { ...state.obj, newProp: 123 }
     ```
 
-### ミューテーション・タイプに定数を使用する
+## ミューテーション・タイプに定数を使用する
 
 いろいろな Flux 実装において、ミューテーション・タイプに定数を使用することが共通して見られるパターンです。これはコードに対してリントツールのようなツールを利用できるという利点があり、また単一ファイルに全ての定数を設定することによって、共同で作業する人に、アプリケーション全体で何のミューテーションが可能であるかを一目見ただけで理解できるようにします:
 
@@ -123,7 +123,7 @@ const store = new Vuex.Store({
 
 定数を使用するかどうかは好みの問題です。多くの開発者による大規模なプロジェクトで役に立ちますが、完全にオプションなので、もしお気に召さなければ使用しなくても構いません。
 
-### ミューテーションは同期的でなければならない
+## ミューテーションは同期的でなければならない
 
 ひとつの重要なルールを覚えておきましょう。それは**ミューテーションハンドラ関数は同期的でなければならない**ということです。なぜか？次の例で考えてみましょう:
 
@@ -139,7 +139,7 @@ mutations: {
 
 いま、開発ツールのミューテーションのログを見ながら、アプリケーションのデバッグを行っていることを想像してください。全てのミューテーションをログに記録するためには、ミューテーションの前後の状態のスナップショットを捕捉することが必要です。しかし、上の例にあるミューテーション内の非同期コールバックは、それを不可能にします: そのコールバックは、ミューテーションがコミットされた時点ではまだ呼び出されていません。そして、コールバックが実際にいつ呼び出されるかを、開発ツールは知る術がありません。いかなる状態変更でも、コールバック内で起きる場合は本質的に追跡不可能です。
 
-### コンポーネント内におけるミューテーションのコミット
+## コンポーネント内におけるミューテーションのコミット
 
 `this.$store.commit('xxx')` と書くか、もしくはコンポーネントのメソッドを `store.commit` にマッピングする `mapMutations` ヘルパーを呼び出すこと（ルートの `store` の注入が必要）で、コンポーネント内でミューテーションをコミットできます:
 
@@ -162,7 +162,7 @@ export default {
 }
 ```
 
-### アクションへ向けて
+## アクションへ向けて
 
 状態変更を非同期に組み合わせることは、プログラムの動きを予測することを非常に困難にします。例えば、状態を変更する非同期コールバックを持った 2つのメソッドを両方呼び出すとき、それらがいつ呼び出されたか、どちらが先に呼び出されたかを、どうやって知ればよいのでしょう？これがまさに、状態変更と非同期の 2つの概念を分離したいという理由です。Vuex では**全てのミューテーションは同期的に行う**という作法になっています:
 

docs/ja/guide/plugins.md

@@ -23,7 +23,7 @@ const store = new Vuex.Store({
 })
 ```
 
-### プラグイン内でのミューテーションのコミット
+## プラグイン内でのミューテーションのコミット
 
 プラグインは直接、状態を変更できません。これはコンポーネントに似ています。プラグインはコンポーネント同様に、ミューテーションのコミットをトリガーすることで状態を変更できます。
 
@@ -54,7 +54,7 @@ const store = new Vuex.Store({
 })
 ```
 
-### 状態のスナップショットを撮る
+## 状態のスナップショットを撮る
 
 時々、状態の"スナップショット"を撮って、ミューテーション前後の状態を比較したくなることがあるでしょう。それを実現するために、状態オブジェクトのディープコピーを行う必要があります:
 
@@ -85,7 +85,7 @@ const store = new Vuex.Store({
 
 上のように記述すれば、プラグインはデフォルトで利用されることになります。本番環境( production ) では、 `process.env.NODE_ENV !== 'production'` を `false` に置き換えるために、 webpack では[DefinePlugin](https://webpack.js.org/plugins/define-plugin/) 、 Browserify では[envify](https://github.com/hughsk/envify) が必要になります。
 
-### ビルトインロガープラグイン
+## ビルトインロガープラグイン
 
 > もし、あなたが [vue-devtools](https://github.com/vuejs/vue-devtools) を使っている場合は、これは不要でしょう。