-
Bad
+悪い例
``` html - +
-
-### Component name casing in JS/JSX strongly recommended
+### JS/JSX 内でのコンポーネント名の形式 強く推奨
-**Component names in JS/[JSX](../guide/render-function.html#JSX) should always be PascalCase, though they may be kebab-case inside strings for simpler applications that only use global component registration through `app.component`.**
+**JS/[JSX](../guide/render-function.html#jsx) 内でのコンポーネント名は常にパスカルケース(PascalCase)にするべきです。ただし、`app.component` で登録したグローバルコンポーネントしか使わないような単純なアプリケーションでは、ケバブケース(kebab-case)を含む文字列になるかもしれません。**
-::: details Detailed Explanation
-In JavaScript, PascalCase is the convention for classes and prototype constructors - essentially, anything that can have distinct instances. Vue components also have instances, so it makes sense to also use PascalCase. As an added benefit, using PascalCase within JSX (and templates) allows readers of the code to more easily distinguish between components and HTML elements.
+::: details 詳細な説明
+JavaScript では、クラスやプロトタイプのコンストラクタは - 原則として異なるインスタンスを持ちうるものはすべて- パスカルケースにするのがしきたりです。Vue コンポーネントもインスタンスをもつので、同じようにパスカルケースにするのが理にかなっています。さらなる利点として、JSX(とテンプレート)の中でパスカルケースを使うことによって、コードを読む人がコンポーネントと HTML 要素をより簡単に見分けられるようになります。
-However, for applications that use **only** global component definitions via `app.component`, we recommend kebab-case instead. The reasons are:
+しかし、`app.component` によるグローバルコンポーネント定義**だけ**を使うアプリケーションでは、代わりにケバブケースを使うことを推奨します。理由は以下の通りです:
-- It's rare that global components are ever referenced in JavaScript, so following a convention for JavaScript makes less sense.
-- These applications always include many in-DOM templates, where [kebab-case **must** be used](#Component-name-casing-in-templates-strongly-recommended).
+- グローバルコンポーネントを JavaScript から参照することはほとんどないので、 JavaScript の原則に従う意味もほとんどありません。
+- そのようなアプリケーションはたくさんの DOM 内テンプレート をもつのが常ですが、 そこでは [ケバブケースを **必ず** 使う必要があります](#テンプレート内でのコンポーネント名の形式-強く推奨)
:::
Good
+良い例
``` html - +
-
Bad
+悪い例
``` js app.component('myComponent', { @@ -925,7 +926,7 @@ export default {
-
-### Full-word component names strongly recommended
+### 完全な単語によるコンポーネント名 強く推奨
-**Component names should prefer full words over abbreviations.**
+**コンポーネント名には、略語よりも完全な単語を使うべきです。**
-The autocompletion in editors make the cost of writing longer names very low, while the clarity they provide is invaluable. Uncommon abbreviations, in particular, should always be avoided.
+長い名前によってもたらされる明快さは非常に貴重ですが、それをタイプする労力はエディタの自動補完によってとても小さくなります。特に、一般的でない略語は常に避けるべきです。
Good
+良い例
``` js app.component('MyComponent', { @@ -951,14 +952,14 @@ export default { ```
-
Bad
+悪い例
``` components/ @@ -968,7 +969,7 @@ components/
-
-### Prop name casing strongly recommended
+### プロパティ名の型式 強く推奨
-**Prop names should always use camelCase during declaration, but kebab-case in templates and [JSX](../guide/render-function.html#JSX).**
+**プロパティ名は、定義の時は常にキャメルケース(camelCase)にするべきですが、テンプレートや [JSX](../guide/render-function.html#JSX) ではケバブケース(kebab-case)にするべきです。**
-We're simply following the conventions of each language. Within JavaScript, camelCase is more natural. Within HTML, kebab-case is.
+私たちは単純にこの慣習に従っています。JavaScript の中ではキャメルケースがより自然で、HTML の中ではケバブケースが自然です。
Good
+良い例
``` components/ @@ -977,14 +978,14 @@ components/ ```
-
Bad
+悪い例
``` js props: { @@ -998,7 +999,7 @@ props: {
-
-### Multi-attribute elements strongly recommended
+### 複数の属性をもつ要素 強く推奨
-**Elements with multiple attributes should span multiple lines, with one attribute per line.**
+**複数の属性をもつ要素は、1 行に 1 要素ずつ、複数の行にわたって書くべきです。**
-In JavaScript, splitting objects with multiple properties over multiple lines is widely considered a good convention, because it's much easier to read. Our templates and [JSX](../guide/render-function.html#JSX) deserve the same consideration.
+JavaScript では、複数のプロパティをもつ要素を複数の行に分けて書くことはよい慣習だと広く考えられています。なぜなら、その方がより読みやすいからです。Vue のテンプレートや [JSX](../guide/render-function.html#JSX) も同じように考えることがふさわしいです。
Good
+良い例
``` js props: { @@ -1011,14 +1012,14 @@ props: { ```
-
@@ -1030,7 +1031,7 @@ In JavaScript, splitting objects with multiple properties over multiple lines is
Bad
+悪い例
``` html
@@ -1030,7 +1031,7 @@ In JavaScript, splitting objects with multiple properties over multiple lines is
-![]()
-### Simple expressions in templates strongly recommended
+### テンプレート内での単純な式 強く推奨
-**Component templates should only include simple expressions, with more complex expressions refactored into computed properties or methods.**
+**複雑な式は算出プロパティかメソッドにリファクタリングして、コンポーネントのテンプレートには単純な式だけを含むようにするべきです。**
-Complex expressions in your templates make them less declarative. We should strive to describe _what_ should appear, not _how_ we're computing that value. Computed properties and methods also allow the code to be reused.
+テンプレート内に複雑な式があると、テンプレートが宣言的ではなくなります。私たちは、_どのように_ その値を算出するかではなく、_何が_ 表示されるべきかを記述するように努力するべきです。また、算出プロパティやメソッドによってコードが再利用できるようになります。
Good
+良い例
``` html
-
Bad
+悪い例
``` html {{ @@ -1067,15 +1068,15 @@ Complex expressions in your templates make them less declarative. We should stri
-
-### Simple computed properties strongly recommended
+### 単純な算出プロパティ 強く推奨
-**Complex computed properties should be split into as many simpler properties as possible.**
+**複雑な算出プロパティは、できる限りたくさんの単純なプロパティに分割するべきです。**
-::: details Detailed Explanation
-Simpler, well-named computed properties are:
+::: details 詳細な説明
+単純な、よい名前を持つ算出プロパティは:
-- __Easier to test__
+- テストしやすい
- When each computed property contains only a very simple expression, with very few dependencies, it's much easier to write tests confirming that it works correctly.
+ それぞれの算出プロパティが、依存がとても少ないごく単純な式だけを含む場合、それが正しく動くことを確認するテストを書くのがより簡単になります。
-- __Easier to read__
+- 読みやすい
- Simplifying computed properties forces you to give each value a descriptive name, even if it's not reused. This makes it much easier for other developers (and future you) to focus in on the code they care about and figure out what's going on.
+ 算出プロパティを単純にするということは、たとえそれが再利用可能ではなかったとしても、それぞれに分かりやすい名前をつけることになります。それによって、他の開発者(そして未来のあなた)が、注意を払うべきコードに集中し、何が起きているかを把握することがより簡単になります。
-- __More adaptable to changing requirements__
+- 要求の変更を受け入れやすい
- Any value that can be named might be useful to the view. For example, we might decide to display a message telling the user how much money they saved. We might also decide to calculate sales tax, but perhaps display it separately, rather than as part of the final price.
+ 名前をつけることができる値は何でも、ビューでも役に立つ可能性があります。例えば、いくら割引になっているかをユーザに知らせるメッセージを表示することに決めたとします。 また、消費税も計算して、最終的な価格の一部としてではなく、別々に表示することにします。
- Small, focused computed properties make fewer assumptions about how information will be used, so require less refactoring as requirements change.
+ 小さく焦点が当てられた算出プロパティは、どのように情報が使われるかの決めつけをより少なくし、少しのリファクタリングで要求の変更を受け入れられます。
:::
Good
+良い例
``` html - + {{ normalizedFullName }} ``` ``` js -// The complex expression has been moved to a computed property +// 複雑な式を算出プロパティに移動 computed: { normalizedFullName() { return this.fullName.split(' ') @@ -1086,30 +1087,30 @@ computed: { ```
-
Bad
+悪い例
``` js computed: { @@ -1125,7 +1126,7 @@ computed: {
-
-### Quoted attribute values strongly recommended
+### 引用符付きの属性値 強く推奨
-**Non-empty HTML attribute values should always be inside quotes (single or double, whichever is not used in JS).**
+**空ではない HTML 属性の値は常に引用符(シングルコーテーションかダブルコーテーション、 JS の中で使われていない方)でくくるべきです。**
-While attribute values without any spaces are not required to have quotes in HTML, this practice often leads to _avoiding_ spaces, making attribute values less readable.
+HTML では、空白を含まない属性値は引用符でくくらなくてもよいことになっていますが、そのせいで空白の使用を _避けてしまい_ 属性値が読みづらくなりがちです。
Good
+良い例
``` js computed: { @@ -1144,14 +1145,14 @@ computed: { ```
-
Bad
+悪い例
``` html @@ -1163,7 +1164,7 @@ While attribute values without any spaces are not required to have quotes in HTM
-
-### Directive shorthands strongly recommended
+### ディレクティブの短縮記法 強く推奨
-**Directive shorthands (`:` for `v-bind:`, `@` for `v-on:` and `#` for `v-slot`) should be used always or never.**
+**ディレクティブの短縮記法 (`v-bind:` に対する `:`、`v-on:` に対する `@`、`v-slot:` に対する `#`)は、常に使うか、まったく使わないかのどちらかにするべきです。**
Good
+良い例
``` html @@ -1174,12 +1175,12 @@ While attribute values without any spaces are not required to have quotes in HTM ```
-
Bad
+悪い例
``` html
-