Vue: HTMLの大文字と小文字の区別の回避策

<MyComponent :myProp="msg"></MyComponent>

+
コンポーネントとタグの違いを確認するために、そのように書きたいことがよくあります

+1

すべてのイベント名を小文字に正規化することは意味がありますか？

はい！ コードが読みやすくなるので、それは理にかなっています。 私は常にイベント名を小文字のままにし、キャメルケースではなくダッシュで区切ります。 キャメルケースのイベント名に警告を追加するのも良いと思います。

これは、VuejsがAngularのような同様のアプローチを追求するHTML仕様から離れることを意味しますか？

パフォーマンス上の懸念はありますか？

潜在的な懸念についてのいくつかの考え：

1. 下位互換性が存在する限り、最終的に決定されたものは何でもかっこいいですが、おそらくケバブケース方式を使用し続けるでしょう
2. キャメルケースと下部キャメルケースの区別がないことは、一部の人にとって混乱を招く可能性があります。 一般的に言えばvar CamelCaseはクラスを参照し、 var camelCaseは非クラス変数var camelCase = new CamelCase();を参照します。 ただし、コンポーネントにちなんで名付けられたクラスを作成したくないので、これが問題になるとは思いません。
3. ケースによってのみ区別される2つの固有のイベントを作成することは、プログラミングが非常に貧弱になることに同意します。

私の最大の懸念は、人々がコーディングする方法に奇妙な矛盾を導入することです。 たとえば、これらはすべて有効で同一です： :myprop="" :myProp="" :mYpRoP="" :my-prop="" 。

👎マークアップにはケバブケースを、コードにはキャメルケースを入れてください。 これはHTML仕様の一部であり、ケースを無視すると、他のフレームワークから来た人や、すでに標準を学習している人にとって、より大きな学習曲線になります。

@Teevioに同意します、一貫性が失われます

HTMLはkebab-caseを使用しており、ECMAScriptがキャメルケース言語であることがコミュニティ標準として認められています。 _hiding_の代わりにそれらを分離しておく必要があります（reactでは、カスタム属性をレンダリングするためにreactを取得できる唯一の方法は、一貫性を強制するdata- *＆aria- *を介することです）。

キャメルケース<-> kebab-caseを_beginner_に（たとえばMDNリンクまたはここで）説明すると、初心者のHTMLの理解に大いに役立ちます。

Evanに同意します。読みやすさとコードの一貫性がより重要です！
+1

私には、HTML内にキャメルケースがあるのは本当に奇妙に見えます。

HTMLはHTML、JSはJS

現在のバージョンは問題ありません

Vueを6か月間使用しているので、それでも毎回私を取得します:( Vueの警告は非常に優れているので大したことではありませんが、私が何をしたかはわかっていますが、ここでアイデアを完全に理解し、+ 1をサポートできます

+1下位互換性もあります。

+1
同意しました。 下位互換性を維持する必要があります。

すべてのイベント名を小文字に正規化することは意味がありますか？

@ azamat-sharapovに同意します

@Teevio Vueコンポーネントは大まかにクラスです。 var MyComp = Vue.extend({ .. })を実行すると、 var myComp = new MyComp()を実行できます。 複数の有効な構文の問題については、すでに存在しています。HTMLはすべてのケース情報を破棄するだけなので、 :my-prop 、 :MY-PROP 、および:mY-pRopすべて現在と同じように機能します。 提案された機能と大差ありません。 すべてのスタイルの議論と同様に、それはすべてスタイルを選び、それに固執することです。

@ jamesxv7 @ moe-szyslak @jonagoldmanや、HTML標準からの移行を懸念しているその他の人々：キャメルケースのタグ/属性をHTMLで記述することは完全に有効です。タグ/属性名の照合は、大文字と小文字を区別せずに実行されます。 。 これは仕様が言うことです：

HTML構文のドキュメント：

HTML要素のタグ名は、このドキュメントのHTML要素セクションに記載されている要素の名前と大文字と小文字を区別しない一致である小文字と大文字の任意の組み合わせで記述できます。 つまり、タグ名では大文字と小文字が区別されません。
HTML要素の属性名は、このドキュメントのHTML要素セクションに記載されている属性の名前と大文字と小文字を区別しない一致である小文字と大文字の任意の組み合わせで記述できます。 つまり、属性名では大文字と小文字が区別されません。

したがって、PascalCase / camelCaseを使用するとコードの一貫性/可読性が向上する場合は、完全に仕様に準拠しています。 これはすべての人に当てはまるわけではありませんが、ケバブケースを好む場合はそれを使い続けることができます。

特に、 @ jamesxv7に関して：これはAngular2が行っていることとは異なります。 Angular 2は、カスタマイズされたHTMLパーサーを導入することにより、テンプレートで大文字と小文字を区別します。 それどころか、Vueは、JSの対応する大文字と小文字を区別しないようにすることで、実際には仕様に従います。

私はケバブをhtmlで保持することを好みます。 私は一貫性のアイデアが好きですが、スペックコンプライアンスのアイデアがもっと好きです。

キャメルケースタグが見つかりました：。 HTMLでは大文字と小文字は区別されません。 つかいます代わりは。 Vueは、JavaScriptのキャメルケースIDで定義されたコンポーネントと自動的に照合します。

この警告は、コンポーネントの登録がどのように機能するかについてはすでにかなり簡潔です。 そうは言っても、他の人が言っているように、ケバブを書き続けるオプションがまだある限り、HTMLでキャメルケースを許可することは素晴らしいことだと思います。

@ yyx990803ええ、同意しました。 それに反対するためにできるだけ多くの議論を考えようとしているだけですが、正直なところ、私には固執するものはありません。 あなたが言ったように、一日の終わりに私たちは文体の選択について議論しています。 私は個人的に、新しいものを使用するオプションを持っている間（しかし強制されないで）私たちがすでに持っているものに固執することができる限り、私は言及された変更でクールだと思います。

ケバブケースがまだ機能し、キャメルケース/パスカルケースを使用することがBCを壊さないオプションである場合、それらを使用するとき、私は追加に反対することはできません。 それは私に何か違うことをさせるような変化ではありません。 これは単なる新しいオプションです。

私が言うことも提案することもできる唯一のことは、このオプションが十分に文書化されていることを確認することです。

スコット

たぶん私たちはそれからオプションを作ることができます：警告または無視。
コンポーネントがあるとしましょう： myComponent
そして私はそれをhtmlでmycompOnentと呼んでいます。私は個人的に次のような警告を好みます。
we found something that would match "myComponent": "mycompOnent" (line 152), use "my-component" instead
もちろん小道具も同じです。
最初の試みで取り組むことよりも、後の読みやすさが重要だと思います。

私はまた、ケバブケース/キャメルケースの問題に遭遇しました。 しかし、本当の問題は、何が悪いのかという警告が表示されなかったことです;）

デフォルトでは、警告はなく、正常に機能する可能性がありますが、それは私には関係ありません。
また、警告はデバッグモードでのみ表示されるはずです。

atone vs a-tone vs at-oneのようなものはどうですか？ しかし、それらは非常にまれな出来事だと思います。

@simplesmiler kebabの大文字と小文字の区別は、古いルールを使用して大文字と小文字の区別と一致します。

これは、Web標準の透明性を促進するものではありません。 カスタム要素の仕様では、名前にはハイフンを含める必要があると規定されています： <my-component/>

@simplesmilerが言ったことはどうですか： addOneとadDoneは同じコードを実行します。 これは、イベントの実装にとって特に厄介です。

また、htmlは大文字と小文字を区別しないため、ライブラリから大文字と小文字を区別するという考えを導入しないでください。 この実装はhtmlのケーシングのみを促進しますが、これは私の意見では悪い考えです。

また、ファイル名にはハイフン区切りを使用します。 そこでもそれらを削除して、ケーシングの追加を開始する必要がありますか？

最後に、ハイフンとケーシングシステムを共存させることで、チームの新しい開発者向けにさまざまなコーディングスタイルを促進します。

私は@paulpflugのアプローチを好みます。 この領域での適切な警告は大いに役立ちます。

私はHTMLPascal / Camelケースを作るのが好きではありません。 それはウェブ標準を破ります、私は一貫性を保つことは素晴らしいことを知っています。

物事を最も小さな一貫性のあるものにしようとすることで、複雑さの別の層を追加します。 それはまた悪い習慣を誘惑するかもしれません。 ライブラリは、開発者を誤解させないように標準を維持することを促進する必要があります。いつの日か、Vueを使用しない場所で作業しなければならず、HTMLが異なる方法で解析される理由がわからなくなる可能性があるためです。

私は@paulpflugに完全に同意します。警告を追加すると、本番コードの作業が減り、開発者は有効なコードを書くことができるようになります。

なぜこれを実装すべきでないのかについての良い議論のケース：http： //eisenbergeffect.bluespire.com/on-angular-2-and-html/

これは一般的に、人々がAngular 2を嫌う理由として強調されています。私は、ライブラリを標準に準拠させることに完全に同意します。 HTMLは大文字と小文字を区別するように作成されていましたが、問題が多すぎて柔軟性が高すぎる状況が発生したために破棄されました。

@ blake-newman：これに関して、 @ yyx990803は以前のコメントですでにそれについて話していると思います。

@ jamesxv7そのコメントはそれをかなりうまくまとめています。 EvanはHTML仕様の変更を提案しているのではなく、Vueがコンポーネント名を見つける方法を変更することを提案しています。 ケバブをラクダに変換して一致するコンポーネントを見つけるのではなく、ダッシュを削除して（ケバブに対応するため）、大文字と小文字を区別せずにコンポーネントを検索します。 HTML自体は引き続き仕様に準拠します。 また、必要なケースを使用できるようになります。 これは私には悪い選択でも悪い選択でもないようです:)

@ yyx990803 <MyComponent>スタイルをプロモートスタイルにする予定ですか（つまり、ドキュメントと例はこのように記述されます）、それとも単なるオプションであり、ケバブケーススタイルが引き続き主要なスタイルになりますか？

@ blake-newmanはこのコメントを読んでいます-それは標準に準拠しています:)

@paulpflug @guidobouman ：最新バージョンのvue-loaderまたはvueifyを使用している場合は、キャメルケースのタグと属性に関する警告がすでに表示されています。 ただし、実行時にHTMLパーサーの動作によりケース情報が既に失われているため、キャメルケースのチェックはコンパイル時に実行する必要があります。 したがって、 vue-loaderまたはvueifyなしでVueを使用している場合、警告は表示されません（できません）。

@ yyx990803-しかし、Webコンポーネント用にリンクされた仕様@ blake-newmanは、次のように述べています。

カスタム要素タイプは、カスタム要素インターフェイスを識別し、NCNameプロダクションと一致する必要があり、_U + 002D HYPHEN-MINUS文字_を含む必要があり、_大文字のASCII文字を含まない必要がある_文字のシーケンスです。

それがVueコンポーネントとどのように関連しているかはよくわかりません。 ドキュメントでは、Webコンポーネントの標準に大まかに従うようにしています。

Vue.jsコンポーネントは、Webコンポーネント仕様の一部であるカスタム要素と非常によく似ていることに気付いたかもしれません。 実際、Vue.jsのコンポーネント構文は仕様に基づいて大まかにモデル化されています。

したがって、キャメルケースとパスカルケースを許可するには、最初に仕様を変更する必要があると思います。

スコット

@smolinari Vueのドキュメントによると、これは「厳密に」ではなく「大まかにモデル化されている」とのことであり、私の考えでは、この変更の余地があります。

@ yyx990803ケース情報が失われる可能性がありますが、それでも警告が表示される可能性があります。
テンプレートに「mycOmponent」と書いた場合、それはmycomponentに解析されますが、期待されるのはmy-componentあるため、Vue（デバッグモード）はmy-component以外に$ mycomponentを探す必要がありますmy-componentそして間違った使用法について私に警告します。 失われたケース情報はここでは重要ではありません。
警告を抑制し、代わりに直接一致させるオプションがあります（提案された動作と同じです）。

-1からキャメルケース/パスカルケースへの移行。 HTMLでJSのような構文を見るのは少し不快です。 jsxに耐えられないのと同じ理由。
@paulpflugの提案に+1。 問題が新人研修の初心者である場合は、ユーザーに問題を通知する警告を発行してみませんか？

有効なアイデアのように聞こえる@paulpflug ！

私は同意します'mycomponent' is missing, did you mean 'my-component'?という警告があると、サイレント置換よりも気分が良くなります。

@ yyx990803グローバルオプションAPIでこれを行うことは可能ですか？
例えば
Vue.config.kebab = true （デフォルト）-> <my-component :my-prop="msg"></my-component>
Vue.config.kebab = false -> <MyComponent :myProp="msg"></MyComponent>

@ yyx990803
ただ疑問に思っているのですが、私たちが目指している理想は何ですか？
@rpkilbyが言ったように、 <MyComponent myCustomProp="myProp" data-name="prop" aria-label="Close" onclick="myDialog.close()">は奇妙に見えます。

基本的に、jsとhtmlは異なるテクノロジーであり、異なる命名システムを使用しているため、問題が存在します。 そして、両方のテクノロジーで同じケース（ケバブまたはラクダ）を使用すると、奇妙さはある場所から別の場所に移りますが、根本的な問題は解決しません
ですから、私たちにできる最善のことは線を引くことだと思います。 そして現在の行、すなわち。 htmlコンテキストのケバブケースとjsコンテキストのcamleCase（およびPascalCase）は非常に優れています。

したがって、IMOでは、より良い規則を探すのではなく、現在の規則をサポートする必要があります。 そしてもちろん、初心者を助けるために警告を使用してください

@ prog-rajkamalええ、私は今、警告を実装する傾向があります。

私は今、警告を追加するだけで：+ 1：に投票します。

スコット

：+1：警告を追加するため

：+1：警告についても

ccf9bede6bc39fb62e43e1efe98136c5f35dae6b＆d7b55c4ee8491dbd853e28a1527050d2d1e7deab経由でクローズ

警告は素晴らしいでしょう。 カスタムイベントが応答されなかった理由を理解するために1時間費やしました（答えはキャメルケースの名前でした）。

PascalCaseコンポーネントまたはプロップのkebab-caseバージョンに応答する対応するコンポーネントまたはプロップがある場合は、警告が表示されます。 イベントでタイプミスをした場合、Vueがそれについてできることはあまりありません。

それとも、 v-on:keyupや@keyupのようなデフォルトの既存のイベント小道具を意味しますか？

テンプレートファイルの@guidoboumanには<my-component v-on:customEvent="myMethod">がありました。 子コンポーネントにthis.$emit('customEvent');がありました。 もちろん、親が聞いている実際のイベントはcustomEvent customeventですが、デバッグが簡単ではないため、それを理解するのに何年もかかりました。 私のような物忘れの人にとっては、キャメルケースの属性がそのように解析されないことを警告するのは良いことだと思っていました。 おそらくこれはすでに上で議論されているので、もしそうなら、私はお詫び申し上げます。

@anthonygoreは残念ながら不可能です。なぜなら、Vueがアクセスする前にブラウザがhtmlを小文字に変換するからです。

私の質問は、なぜVueが私たちのためにそれを変換できないのですか？ なぜケバブについて覚えておく必要があるのですか？

メモリにコミットする1つのルール： HTML = kebab-case, JavaScript = camelCase

HTMLとは、属性とタグを意味します。 v-bindを使用する場合、属性値はJavaScript式であるため、2番目のステートメントが適用されます。

私の質問は、なぜVueが私たちのためにそれを変換できないのですか？ なぜvueファイルのkebab-caseについて覚えておく必要があるのですか？ それは初心者にとって物事をより厄介にします...私はちょうどそのために最後の20分を無駄にしました...

私はそれをググっただけではなかったので、最後の1.5時間無駄になりました... dxmn