v2.x 以前のドキュメントです。 v3.x のドキュメントを見たい場合はこちら

スタイルガイド

最終更新日: 2021年5月22日

このドキュメントは、 Vue 固有の記法についての公式なスタイルガイドです。もしあなたがプロジェクトにおいて Vue を使用する場合は、エラーや有益でない議論、アンチパターンを避けるための参考となります。しかし、スタイルガイドはすべてのチームやプロジェクトで理想とは限らないと考えていますので、過去の経験や、周囲の技術スタック、個人の価値観に基づいた上で必要に応じて慎重に逸脱することが推奨されます。

ほとんどのパートにおいて、基本的に JavaScript や HTML に対する提案はさけています。セミコロンやカンマの使用の是非はどちらでも良いです。 HTML の属性に対してシングルクォートかダブルクォートどちらかを利用するかもどちらでも良いです。しかし、特定のパターンにおいて Vue のコンテキストが役立つと判明した場合については、その限りではありません。

近々、実施のヒントを提供予定です。 スタイルガイドについて、必要に応じて自身で実施しなければならない場所もありますが、可能な限り ESLint やその他自動化されたプロセスを用いて、より簡単に行う方法を明示します。

最後に、私たちはルール群を 4 つのカテゴリに分割しました:

ルールカテゴリ

優先度 A: 必須

これらのルールは、エラー防止に役立ちます。ですので、学び、遵守してください。例外は存在するかもしれませんが、それらは極めて稀で、かつ JavaScript と Vue の両方の専門知識を持った人によってのみ作られるべきです。

優先度 B: 強く推奨

これらのルールは、ほとんどのプロジェクトで読みやすさや開発者の体験をよりよくするために見いだされました。これらに違反してもあなたのコードは動きますが、ごくまれなケースで、かつちゃんと正当を示した上でのみ違反するようにすべきです。

優先度 C: 推奨

同じくらい良いオプションが複数ある場合､一貫性を確保するために任意の選択をすることができます｡これらのルールでは､それぞれ許容可能なオプションを説明し､既定の選択を提案します｡つまり､一貫性があり､良い理由を持ち続ける限り､独自のコードベースで自由に異なる選択肢を作ることができます｡ですが､良い理由はあるのでしょうか！コミュニティの標準に合わせることで､あなたは:

1. 直面するコミュニティのコードを容易に理解できるように脳を慣れさせます｡
2. ほとんどのコミュニティのコードサンプルを変更なしにコピーして貼り付ける事ができます｡
3. 少なくとも Vue に関しては､ほとんどの場合､新たな人材はあなたのコーディングスタイルよりも既に慣れ親しんだものを好みます｡

優先度 D: 使用注意

Vue のいくつかの機能は、レアケースまたは従来のコードベースからスムーズな移行に対応するために存在します。しかしながら、これを使いすぎると、コードを保守することが難しくなり、またバグの原因になることさえあります。これらのルールは潜在的な危険な機能を照らし、いつ、なぜ避けなかればならないのかを説明しています。

優先度 A ルール: 必須 (エラー防止)

複数単語コンポーネント名 ^必須

ルートの App コンポーネントや、Vue が提供する <transition> や <component> のようなビルトインコンポーネントを除き、コンポーネント名は常に複数単語とするべきです。

これは、全ての HTML 要素は 1 単語となっているというこれまでの経緯から、既に存在する、そして将来定義される HTML 要素との衝突を防止します。

Vue.component('todo', {
  // ...
})

export default {
  name: 'Todo',
  // ...
}

Vue.component('todo-item', {
  // ...
})

export default {
  name: 'TodoItem',
  // ...
}

コンポーネントのデータ ^必須

コンポーネントの data は関数でなければなりません。

コンポーネントで data プロパティを使用する際 (つまり new Vue 以外のどこでも)、その値はオブジェクトを返す関数でなければなりません。

data: {
  listTitle: '',
  todos: []
}

data: function () {
  return {
    listTitle: '',
    todos: []
  }
}

Vue.component('some-comp', {
  data: {
    foo: 'bar'
  }
})

export default {
  data: {
    foo: 'bar'
  }
}

Vue.component('some-comp', {
  data: function () {
    return {
      foo: 'bar'
    }
  }
})

// .vue ファイル内
export default {
  data () {
    return {
      foo: 'bar'
    }
  }
}

// ルートで直接オブジェクトを使うのは OK です
// なぜなら Vue インスタンスはずっと存在する唯一のインスタンスだからです
new Vue({
  data: {
    foo: 'bar'
  }
})

プロパティの定義 ^必須

プロパティの定義はできる限り詳細とするべきです。

コミットされたコード内で、プロパティの定義は常に少なくとも1つのタイプを指定し、できる限り詳細とするべきです。

// プロトタイピングの時だけ OK
props: ['status']

props: {
  status: String
}

// さらに良いです!
props: {
  status: {
    type: String,
    required: true,
    validator: function (value) {
      return [
        'syncing',
        'synced',
        'version-conflict',
        'error'
      ].indexOf(value) !== -1
    }
  }
}

キー付き v-for ^必須

常に v-for に対しては key を使用してください。

サブツリー下に内部コンポーネントの状態を維持するために v-for に key は 常に コンポーネントに必要です。それが要素の場合においても、 アニメーションにおける オブジェクトの一貫性 のような予測可能な振る舞いを維持するためには良い手法でしょう。

data: function () {
  return {
    todos: [
      {
        id: 1,
        text: 'Learn to use v-for'
      },
      {
        id: 2,
        text: 'Learn to use key'
      }
    ]
  }
}

<ul>
  <li v-for="todo in todos">
    {{ todo.text }}
  </li>
</ul>

<ul>
  <li
    v-for="todo in todos"
    :key="todo.id"
  >
    {{ todo.text }}
  </li>
</ul>

v-for と一緒に v-if を使うのを避ける ^必須

v-for と同じ要素に v-if を使わないでください。

こうしたくなってしまう2つの一般的なケースがあります:

• リスト内のアイテムをフィルタする(例: v-for="user in users" v-if="user.isActive")。このような場合は、フィルタリングされたリストを返却する算出プロパティに users を置き換えてください(例: activeUsers)。

• 非表示にする必要がある場合、リストを描画しないようにする(例: v-for="user in users" v-if="shouldShowUsers")。このような場合は、v-if をコンテナ要素(例: ul、ol)に移動してください。

<ul>
  <li
    v-for="user in users"
    v-if="user.isActive"
    :key="user.id"
  >
    {{ user.name }}
  </li>
</ul>

this.users.map(function (user) {
  if (user.isActive) {
    return user.name
  }
})

computed: {
  activeUsers: function () {
    return this.users.filter(function (user) {
      return user.isActive
    })
  }
}

<ul>
  <li
    v-for="user in activeUsers"
    :key="user.id"
  >
    {{ user.name }}
  </li>
</ul>

<ul>
  <li
    v-for="user in users"
    v-if="shouldShowUsers"
    :key="user.id"
  >
    {{ user.name }}
  </li>
</ul>

<ul v-if="shouldShowUsers">
  <li
    v-for="user in users"
    :key="user.id"
  >
    {{ user.name }}
  </li>
</ul>

<ul>
  <li
    v-for="user in users"
    v-if="user.isActive"
    :key="user.id"
  >
    {{ user.name }}
  </li>
</ul>

<ul>
  <li
    v-for="user in users"
    v-if="shouldShowUsers"
    :key="user.id"
  >
    {{ user.name }}
  </li>
</ul>

<ul>
  <li
    v-for="user in activeUsers"
    :key="user.id"
  >
    {{ user.name }}
  </li>
</ul>

<ul v-if="shouldShowUsers">
  <li
    v-for="user in users"
    :key="user.id"
  >
    {{ user.name }}
  </li>
</ul>

コンポーネントスタイルのスコープ ^必須

アプリケーションにとって、トップレベルの App コンポーネントとレイアウトコンポーネント内のスタイルはグローバルかもしれませんが、他のすべてのコンポーネントは常にスコープされているべきです。

これは単一ファイルコンポーネントにのみ関係します。 scoped 属性の使用は必須ではありません。スコープは CSS modules 、 BEM のようなクラスに基づいた戦略、あるいは他のライブラリや慣例を介して行うことができます。

しかしながら、コンポーネントライブラリでは scoped 属性を使用する代わりに、クラスに基づいた戦略の方がむしろ好ましいです。

これは内部スタイルの上書きを容易にし、人間が読みやすいクラス名は高い詳細度を持ちませんが、しかし依然として衝突する可能性はほとんどありません。

<template>
  <button class="btn btn-close">X</button>
</template>

<style>
.btn-close {
  background-color: red;
}
</style>

<template>
  <button class="button button-close">X</button>
</template>

<!-- `scoped` を使用 -->
<style scoped>
.button {
  border: none;
  border-radius: 2px;
}

.button-close {
  background-color: red;
}
</style>

<template>
  <button :class="[$style.button, $style.buttonClose]">X</button>
</template>

<!-- CSS modules を使用 -->
<style module>
.button {
  border: none;
  border-radius: 2px;
}

.buttonClose {
  background-color: red;
}
</style>

<template>
  <button class="c-Button c-Button--close">X</button>
</template>

<!-- BEM の慣例を使用 -->
<style>
.c-Button {
  border: none;
  border-radius: 2px;
}

.c-Button--close {
  background-color: red;
}
</style>

プライベートなプロパティ名 ^必須

プライベートな関数に外部からアクセスできないようにするために、モジュールスコープを使用してください。それが難しい場合は、プラグインやミックスインなどのプライベートなカスタムプロパティには常に $_ プレフィックスを使用してください。さらに、他の著者によるコードとの衝突を避けるため、名前付きのスコープを含めてください (例 $_yourPluginName_ )。

var myGreatMixin = {
  // ...
  methods: {
    update: function () {
      // ...
    }
  }
}

var myGreatMixin = {
  // ...
  methods: {
    _update: function () {
      // ...
    }
  }
}

var myGreatMixin = {
  // ...
  methods: {
    $update: function () {
      // ...
    }
  }
}

var myGreatMixin = {
  // ...
  methods: {
    $_update: function () {
      // ...
    }
  }
}

var myGreatMixin = {
  // ...
  methods: {
    $_myGreatMixin_update: function () {
      // ...
    }
  }
}

// さらによい!
var myGreatMixin = {
  // ...
  methods: {
    publicMethod() {
      // ...
      myPrivateFunction()
    }
  }
}

function myPrivateFunction() {
  // ...
}

export default myGreatMixin

優先度B のルール: 強く推奨 (読みやすさの向上)

コンポーネントのファイル ^強く推奨

ファイルを結合してくれるビルドシステムがあるときは必ず、各コンポーネントはそれぞれ別のファイルに書くべきです。

そうすれば、コンポーネントを編集したり使い方を確認するときにより素早く見つけることができます。

Vue.component('TodoList', {
  // ...
})

Vue.component('TodoItem', {
  // ...
})

components/
|- TodoList.js
|- TodoItem.js

components/
|- TodoList.vue
|- TodoItem.vue

単一ファイルコンポーネントのファイル名の形式 ^強く推奨

単一ファイルコンポーネント のファイル名は、すべてパスカルケース (PascalCase) にするか、すべてケバブケース (kebab-case) にするべきです。

パスカルケースは、JS(X) やテンプレートの中でコンポーネントを参照する方法と一致しているので、コードエディタ上でオートコンプリートが可能な場合はとてもうまく働きます。しかし、大文字と小文字が混ざったファイル名は、大文字と小文字を区別しないファイルシステム上で時々問題を起こす可能性があります。そのため、ケバブケースもまた完全に受け入れられています。

components/
|- mycomponent.vue

components/
|- myComponent.vue

components/
|- MyComponent.vue

components/
|- my-component.vue

基底コンポーネントの名前 ^強く推奨

アプリケーション特有のスタイルやルールを適用する基底コンポーネント (またはプレゼンテーションコンポーネント: Presentation Components、ダムコンポーネント: Dumb Components、純粋コンポーネント: Pure Components とも) は、すべて Base 、 App 、V などの固有のプレフィックスで始まるべきです。

components/
|- MyButton.vue
|- VueTable.vue
|- Icon.vue

components/
|- BaseButton.vue
|- BaseTable.vue
|- BaseIcon.vue

components/
|- AppButton.vue
|- AppTable.vue
|- AppIcon.vue

components/
|- VButton.vue
|- VTable.vue
|- VIcon.vue

単一インスタンスのコンポーネント名 ^強く推奨

常に 1 つのアクティブなインスタンスしか持たないコンポーネントは、1 つしか存在しえないことを示すために The というプレフィックスで始めるべきです。

これはそのコンポーネントが 1 つのページでしか使われないということを意味するのではなく、 ページごとに 1 回しか使われないという意味です。これらのコンポーネントは、アプリケーション内のコンテキストではなく、アプリケーションに対して固有のため、決してプロパティを受け入れることはありません。もしプロパティを追加する必要があることに気づいたのなら、それは 現時点で ページごとに 1 回しか使われていないだけで、実際には再利用可能なコンポーネントだということを示すよい目印です。

components/
|- Heading.vue
|- MySidebar.vue

components/
|- TheHeading.vue
|- TheSidebar.vue

密結合コンポーネントの名前 ^強く推奨

親コンポーネントと密結合した子コンポーネントには、親コンポーネントの名前をプレフィックスとして含むべきです。

もし、コンポーネントが単一の親コンポーネントの中でだけ意味をもつものなら、その関連性は名前からはっきりわかるようにするべきです。一般的にエディタはファイルをアルファベット順に並べるので、関連をもつものどうしが常に隣り合って並ぶことにもなります。

components/
|- TodoList/
   |- Item/
      |- index.vue
      |- Button.vue
   |- index.vue

components/
|- TodoList/
   |- Item/
      |- Button.vue
   |- Item.vue
|- TodoList.vue

components/
|- TodoList.vue
|- TodoItem.vue
|- TodoButton.vue

components/
|- SearchSidebar.vue
|- NavigationForSearchSidebar.vue

components/
|- TodoList.vue
|- TodoListItem.vue
|- TodoListItemButton.vue

components/
|- SearchSidebar.vue
|- SearchSidebarNavigation.vue

コンポーネント名における単語の順番 ^強く推奨

コンポーネント名は、最高レベルの(たいていは最も一般的な)単語から始めて、説明的な修飾語で終わるべきです。

components/
|- ClearSearchButton.vue
|- ExcludeFromSearchInput.vue
|- LaunchOnStartupCheckbox.vue
|- RunSearchButton.vue
|- SearchInput.vue
|- TermsCheckbox.vue

components/
|- SearchButtonClear.vue
|- SearchButtonRun.vue
|- SearchInputExcludeGlob.vue
|- SearchInputQuery.vue
|- SettingsCheckboxLaunchOnStartup.vue
|- SettingsCheckboxTerms.vue

components/
|- ClearSearchButton.vue
|- ExcludeFromSearchInput.vue
|- LaunchOnStartupCheckbox.vue
|- RunSearchButton.vue
|- SearchInput.vue
|- TermsCheckbox.vue

components/
|- SearchButtonClear.vue
|- SearchButtonRun.vue
|- SearchInputQuery.vue
|- SearchInputExcludeGlob.vue
|- SettingsCheckboxTerms.vue
|- SettingsCheckboxLaunchOnStartup.vue

自己終了形式のコンポーネント ^強く推奨

中身を持たないコンポーネントは、 単一ファイルコンポーネント 、文字列テンプレート、および JSX の中では自己終了形式で書くべきです。ただし、DOM テンプレート内ではそうしてはいけません。

自己終了形式のコンポーネントは、単に中身を持たないというだけでなく、中身を持たないことを 意図したものだ ということをはっきりと表現します。本の中にある白紙のページと、「このページは意図的に白紙のままにしています」と書かれたページとは違うということです。また、不要な閉じタグがなくなることによってあなたのコードはより読みやすくなります。

残念ながら、HTML はカスタム要素の自己終了形式を許していません。公式の「空」要素 だけです。これが、Vue のテンプレートコンパイラが DOM よりも先にテンプレートにアクセスして、その後 DOM の仕様に準拠した HTML を出力することができる場合にだけこの方策を使うことができる理由です。

<!-- 単一ファイルコンポーネント、文字列テンプレート、JSX の中 -->
<MyComponent></MyComponent>

<!-- DOM テンプレートの中 -->
<my-component/>

<!-- 単一ファイルコンポーネント、文字列テンプレート、JSX の中 -->
<MyComponent/>

<!-- DOM テンプレートの中 -->
<my-component></my-component>

テンプレート内でのコンポーネント名の形式 ^強く推奨

ほとんどのプロジェクトでは、コンポーネント名は 単一ファイルコンポーネント と文字列テンプレートの中では常にパスカルケース(PascalCase)になるべきです。 - しかし、 DOM テンプレートの中ではケバブケース(kebab-case)です。

パスカルケースには、ケバブケースよりも優れた点がいくつかあります:

• パスカルケースは JavaScript でも使われるので、エディタがテンプレート内のコンポーネント名を自動補完できます。
• <MyComponent> は <my-component> よりも一単語の HTML 要素との見分けがつきやすいです。なぜなら、ハイフン 1 文字だけの違いではなく 2 文字(2 つの大文字) の違いがあるからです。
• もし、テンプレート内で、例えば Web コンポーネントのような Vue 以外のカスタム要素を使っていたとしても、パスカルケースは Vue コンポーネントがはっきりと目立つことを保証します。

残念ですが、HTML は大文字と小文字を区別しないので、DOM テンプレートの中ではまだケバブケースを使う必要があります。

ただし、もしあなたが既にケバブケースを大量に使っているのなら、HTML の慣習との一貫性を保ちすべてのあなたのプロジェクトで同じ型式を使えるようにすることはおそらく上にあげた利点よりも重要です。このような状況では、 どこでもケバブケースを使うのもアリです。

<!-- 単一ファイルコンポーネント、文字列テンプレートの中 -->
<mycomponent/>

<!-- 単一ファイルコンポーネント、文字列テンプレートの中 -->
<myComponent/>

<!-- DOM テンプレートの中 -->
<MyComponent></MyComponent>

<!-- 単一ファイルコンポーネント、文字列テンプレートの中 -->
<MyComponent/>

<!-- DOM テンプレートの中 -->
<my-component></my-component>

<!-- どこでも -->
<my-component></my-component>

JS/JSX 内でのコンポーネント名の形式 ^強く推奨

JS/JSX 内でのコンポーネント名はつねにパスカルケース(PascalCase)にするべきです。ただし、 Vue.component で登録したグローバルコンポーネントしか使わないような単純なアプリケーションでは、ケバブケース(kebab-case)を含む文字列になるかもしれません。

Vue.component('myComponent', {
  // ...
})

import myComponent from './MyComponent.vue'

export default {
  name: 'myComponent',
  // ...
}

export default {
  name: 'my-component',
  // ...
}

Vue.component('MyComponent', {
  // ...
})

Vue.component('my-component', {
  // ...
})

import MyComponent from './MyComponent.vue'

export default {
  name: 'MyComponent',
  // ...
}

完全な単語によるコンポーネント名 ^強く推奨

コンポーネント名には、略語よりも完全な単語を使うべきです。

長い名前によってもたらされる明快さは非常に貴重ですが、それをタイプする労力はエディタの自動補完によってとても小さくなります。特に、一般的でない略語は常に避けるべきです。

components/
|- SdSettings.vue
|- UProfOpts.vue

components/
|- StudentDashboardSettings.vue
|- UserProfileOptions.vue

プロパティ名の型式 ^強く推奨

プロパティ名は、定義の時は常にキャメルケース(camelCase)にするべきですが、テンプレートや JSX ではケバブケース(kebab-case)にするべきです。

私たちは単純にこの慣習に従っています。JavaScript の中ではキャメルケースがより自然で、HTML の中ではケバブケースが自然です。

props: {
  'greeting-text': String
}

<WelcomeMessage greetingText="hi"/>

props: {
  greetingText: String
}

<WelcomeMessage greeting-text="hi"/>

複数の属性をもつ要素 ^強く推奨

複数の属性をもつ要素は、1 行に 1 要素ずつ、複数の行にわたって書くべきです。

JavaScript では、複数のプロパティをもつ要素を複数の行に分けて書くことはよい慣習だと広く考えられています。なぜなら、その方がより読みやすいからです。Vue のテンプレートや JSX も同じように考えることがふさわしいです。

<img src="https://vuejs.org/images/logo.png" alt="Vue Logo">

<MyComponent foo="a" bar="b" baz="c"/>

<img
  src="https://vuejs.org/images/logo.png"
  alt="Vue Logo"
>

<MyComponent
  foo="a"
  bar="b"
  baz="c"
/>

テンプレート内での単純な式 ^強く推奨

複雑な式は算出プロパティかメソッドにリファクタリングして、コンポーネントのテンプレートには単純な式だけを含むようにするべきです。

テンプレート内に複雑な式があると、テンプレートが宣言的ではなくなります。私たちは、 どのように その値を算出するかではなく、 何が 表示されるべきかを記述するように努力するべきです。また、算出プロパティやメソッドによってコードが再利用できるようになります。

{{
  fullName.split(' ').map(function (word) {
    return word[0].toUpperCase() + word.slice(1)
  }).join(' ')
}}

<!-- テンプレート内 -->
{{ normalizedFullName }}

// 複雑な式を算出プロパティに移動
computed: {
  normalizedFullName: function () {
    return this.fullName.split(' ').map(function (word) {
      return word[0].toUpperCase() + word.slice(1)
    }).join(' ')
  }
}

単純な算出プロパティ ^強く推奨

複雑な算出プロパティは、できる限りたくさんの単純なプロパティに分割するべきです。

computed: {
  price: function () {
    var basePrice = this.manufactureCost / (1 - this.profitMargin)
    return (
      basePrice -
      basePrice * (this.discountPercent || 0)
    )
  }
}

computed: {
  basePrice: function () {
    return this.manufactureCost / (1 - this.profitMargin)
  },
  discount: function () {
    return this.basePrice * (this.discountPercent || 0)
  },
  finalPrice: function () {
    return this.basePrice - this.discount
  }
}

引用符付きの属性値 ^強く推奨

空ではない HTML 属性の値は常に引用符(シングルコーテーションかダブルコーテーション、 JS の中で使われていない方)でくくるべきです。

HTML では、空白を含まない属性値は引用符でくくらなくてもよいことになっていますが、そのせいで空白の使用を 避けてしまい 属性値が読みづらくなることをしばしばもたらします。

<input type=text>

<AppSidebar :style={width:sidebarWidth+'px'}>

<input type="text">

<AppSidebar :style="{ width: sidebarWidth + 'px' }">

ディレクティブの短縮記法 ^強く推奨

ディレクティブの短縮記法 (v-bind: に対する : 、 v-on: に対する @ 、 v-slot: に対する #)は、常に使うか、まったく使わないかのどちらかにするべきです。

<input
  v-bind:value="newTodoText"
  :placeholder="newTodoInstructions"
>

<input
  v-on:input="onInput"
  @focus="onFocus"
>

<template v-slot:header>
  <h1>Here might be a page title</h1>
</template>

<template #footer>
  <p>Here's some contact info</p>
</template>

<input
  :value="newTodoText"
  :placeholder="newTodoInstructions"
>

<input
  v-bind:value="newTodoText"
  v-bind:placeholder="newTodoInstructions"
>

<input
  @input="onInput"
  @focus="onFocus"
>

<input
  v-on:input="onInput"
  v-on:focus="onFocus"
>

<template v-slot:header>
  <h1>Here might be a page title</h1>
</template>

<template v-slot:footer>
  <p>Here's some contact info</p>
</template>

<template #header>
  <h1>Here might be a page title</h1>
</template>

<template #footer>
  <p>Here's some contact info</p>
</template>

優先度 C のルール: 推奨 (任意の選択肢と認知上のオーバーヘッドの最小化)

コンポーネント/インスタンス オプション順序 ^推奨

コンポーネント/インスタンス オプションは､一貫した順序になるべきです｡

これは推奨するコンポーネントオプションの既定の順序です｡それらは種類分けされており､プラグインからどこに新たなプロパティを追加するか知ることができます｡

1. 副作用 (コンポーネント外への影響)

   • el

2. グローバルな認識 (コンポーネントを超えた知識が必要)

   • name
   • parent

3. コンポーネントの種類 (コンポーネントの種類を変更)

   • functional

4. テンプレートの修飾子 (テンプレートのコンパイル方法を変更)

   • delimiters
   • comments

5. テンプレートの依存関係 (テンプレートで使用されるアセット)

   • components
   • directives
   • filters

6. 合成 (プロパティをオプションにマージ)

   • extends
   • mixins

7. インタフェース (コンポーネントへのインタフェース)

   • inheritAttrs
   • model
   • props/propsData

8. ローカルの状態 (ローカル リアクティブ プロパティ)

   • data
   • computed

9. イベント (リアクティブなイベントによって引き起こされたコールバック)

   • watch
   • ライフサイクルイベント (呼び出される順)
     • beforeCreate
     • created
     • beforeMount
     • mounted
     • beforeUpdate
     • updated
     • activated
     • deactivated
     • beforeDestroy
     • destroyed

10. リアクティブではないプロパティ (リアクティブシステムから独立したインスタンス プロパティ)

    • methods

11. レンダリング (コンポーネント出力の宣言的な記述)

    • template/render
    • renderError

要素の属性の順序 ^推奨

要素の属性 (コンポーネントを含む) は､一貫した順序になるべきです｡

これは推奨するコンポーネントオプションの既定の順序です｡それらは種類分けされており､カスタム属性とディレクティブをどこに追加するか知ることができます｡

1. 定義 (コンポーネントオプションを提供)

   • is

2. リスト描画 (同じ要素の複数のバリエーションを作成する)

   • v-for

3. 条件 (要素が描画/表示されているかどうか)

   • v-if
   • v-else-if
   • v-else
   • v-show
   • v-cloak

4. 描画修飾子 (要素の描画方法を変更)

   • v-pre
   • v-once

5. グローバルな認識 (コンポーネントを超えた知識が必要)

   • id

6. 一意の属性 (一意の値を必要とする属性)

   • ref
   • key

7. 双方向バインディング (バインディングとイベントの結合)

   • v-model

8. その他の属性 (すべての指定されていないバインドされた属性とバインドされていない属性)

9. イベント (コンポーネントのイベントリスナ)

   • v-on

10. コンテンツ (要素のコンテンツを上書きする)

    • v-html
    • v-text

コンポーネント/インスタンス オプションの空行 ^推奨

特にオプションがスクロールなしでは画面に収まらなくなった場合､複数行に渡るプロパティの間に空行を追加してみてください｡

コンポーネントに窮屈さや読みづらさを感じたら､複数行に渡るプロパティの間に空行を追加する事でそれらを簡単に読み流すことができるようになります｡ Vim など､一部のエディタでは、このような書式を使用するとキーボードで簡単に移動することができます。

props: {
  value: {
    type: String,
    required: true
  },

  focused: {
    type: Boolean,
    default: false
  },

  label: String,
  icon: String
},

computed: {
  formattedValue: function () {
    // ...
  },

  inputClasses: function () {
    // ...
  }
}

// コンポーネントの読み取りや移動が容易であれば、
// 空行がなくても大丈夫です｡
props: {
  value: {
    type: String,
    required: true
  },
  focused: {
    type: Boolean,
    default: false
  },
  label: String,
  icon: String
},
computed: {
  formattedValue: function () {
    // ...
  },
  inputClasses: function () {
    // ...
  }
}

単一ファイルコンポーネントのトップレベルの属性の順序 ^推奨

単一ファイルコンポーネントでは､ <script> ､ <template> ､ <style> タグを一貫した順序にするべきです､ <style> は最後です､それは他の2つのうち少なくとも1つが常に必要だからです。

<style>/* ... */</style>
<script>/* ... */</script>
<template>...</template>

<!-- ComponentA.vue -->
<script>/* ... */</script>
<template>...</template>
<style>/* ... */</style>

<!-- ComponentB.vue -->
<template>...</template>
<script>/* ... */</script>
<style>/* ... */</style>

<!-- ComponentA.vue -->
<script>/* ... */</script>
<template>...</template>
<style>/* ... */</style>

<!-- ComponentB.vue -->
<script>/* ... */</script>
<template>...</template>
<style>/* ... */</style>

<!-- ComponentA.vue -->
<template>...</template>
<script>/* ... */</script>
<style>/* ... */</style>

<!-- ComponentB.vue -->
<template>...</template>
<script>/* ... */</script>
<style>/* ... */</style>

優先度 D のルール: 使用注意（潜在的に危険なパターン）

key を使わない v-if/v-else-if/v-else ^使用注意

それらが同じ種類の要素の場合、通常は v-if + v-else と一緒に key を使用するのが最善です(例: どちらも <div> 要素).

デフォルトでは、Vue は可能な限り効率的に DOM を更新します。これは、同じ種類の要素間を切り替えるときに、既存の要素を取り除いてそこに新しい要素を作成するのではなく、単純に既存の要素を修正することを意味します。これらの要素が、実際には同一とみなされないほうが良い場合、予期せぬ結果を起こすことがあります。

<div v-if="error">
  Error: {{ error }}
</div>
<div v-else>
  {{ results }}
</div>

<div
  v-if="error"
  key="search-status"
>
  Error: {{ error }}
</div>
<div
  v-else
  key="search-results"
>
  {{ results }}
</div>

scoped 付きの要素セレクタ ^使用注意

scoped 付きの要素セレクタは避けるべきです。

たくさんの要素セレクタは低速なため、scoped 付きの要素セレクタよりも、クラスセレクタを使用します。

<template>
  <button>X</button>
</template>

<style scoped>
button {
  background-color: red;
}
</style>

<template>
  <button class="btn btn-close">X</button>
</template>

<style scoped>
.btn-close {
  background-color: red;
}
</style>

暗黙的な親子間のやりとり ^使用注意

親子間のやりとりは、this.$parent や変化するプロパティよりも、プロパティとイベントが推奨されます。

理想的な Vue アプリケーションでは、props down, events up となります。この習慣に従えば、コンポーネントの理解が簡単になります。ですが、プロパティの変化や this.$parent が、深く結合している2つのコンポーネントを単純化できるようなエッジケースも存在します。

問題は、これらのパターンが便利になるような、シンプルな ケースも多く存在することです。注意: 短期間の利便性（少ないコードを書くこと）のための、取引のシンプルさ(状態の流れを理解出来るようになる)に誘惑されないでください。

Vue.component('TodoItem', {
  props: {
    todo: {
      type: Object,
      required: true
    }
  },
  template: '<input v-model="todo.text">'
})

Vue.component('TodoItem', {
  props: {
    todo: {
      type: Object,
      required: true
    }
  },
  methods: {
    removeTodo () {
      var vm = this
      vm.$parent.todos = vm.$parent.todos.filter(function (todo) {
        return todo.id !== vm.todo.id
      })
    }
  },
  template: `
    <span>
      {{ todo.text }}
      <button @click="removeTodo">
        X
      </button>
    </span>
  `
})

Vue.component('TodoItem', {
  props: {
    todo: {
      type: Object,
      required: true
    }
  },
  template: `
    <input
      :value="todo.text"
      @input="$emit('input', $event.target.value)"
    >
  `
})

Vue.component('TodoItem', {
  props: {
    todo: {
      type: Object,
      required: true
    }
  },
  template: `
    <span>
      {{ todo.text }}
      <button @click="$emit('delete')">
        X
      </button>
    </span>
  `
})

Flux 以外の状態管理 ^使用注意

グローバル状態管理には、this.$root やグローバルイベントバスよりも、Vuex が推奨されます

this.$root や グローバルイベントバス を使用した状態管理は非常にシンプルなケースでは便利かもしれませんが、ほとんどのアプリケーションにとっては適切ではありません。

Vuex は Vue の公式 Flux ライクな実装で、状態管理のための中心地だけではなく、整理、追跡、そして状態変更のデバッグのためのツールも提供します。Vuex は Vue のエコシステムにうまく統合されています（Vue DevTools のフルサポートを含みます）。

// main.js
new Vue({
  data: {
    todos: []
  },
  created: function () {
    this.$on('remove-todo', this.removeTodo)
  },
  methods: {
    removeTodo: function (todo) {
      var todoIdToRemove = todo.id
      this.todos = this.todos.filter(function (todo) {
        return todo.id !== todoIdToRemove
      })
    }
  }
})

// store/modules/todos.js
export default {
  state: {
    list: []
  },
  mutations: {
    REMOVE_TODO (state, todoId) {
      state.list = state.list.filter(todo => todo.id !== todoId)
    }
  },
  actions: {
    removeTodo ({ commit, state }, todo) {
      commit('REMOVE_TODO', todo.id)
    }
  }
}

<!-- TodoItem.vue -->
<template>
  <span>
    {{ todo.text }}
    <button @click="removeTodo(todo)">
      X
    </button>
  </span>
</template>

<script>
import { mapActions } from 'vuex'

export default {
  props: {
    todo: {
      type: Object,
      required: true
    }
  },
  methods: mapActions(['removeTodo'])
}
</script>