Vue: Problemumgehung für HTML-Groß-/Kleinschreibung

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

+
Ich möchte oft so schreiben, um den Unterschied zwischen den Komponenten und Tags zu sehen

+1

Ist es sinnvoll, alle Ereignisnamen in Kleinbuchstaben zu normalisieren?

Ja! Es ist sinnvoll, weil es den Code lesbarer macht. Ich halte Ereignisnamen immer in Kleinbuchstaben und trenne sie durch Bindestriche anstelle von Camelcase. Ich denke, das Hinzufügen einer Warnung für Camelcase-Ereignisnamen wäre auch gut.

Bedeutet dies, dass Vuejs sich von der HTML-Spezifikation entfernen und einen ähnlichen Ansatz wie Angular verfolgen wird?

Gibt es Leistungsbedenken?

Ein paar Gedanken zu möglichen Bedenken:

1. Solange die Abwärtskompatibilität besteht, werde ich mit dem, was letztendlich entschieden wird, cool sein, werde aber wahrscheinlich weiterhin die Kebab-Fall-Methode verwenden
2. Die fehlende Unterscheidung zwischen Camel-Case und Lower Camel-Case könnte für einige verwirrend sein. Im Allgemeinen bezieht sich var CamelCase auf eine Klasse und var camelCase auf eine Nicht-Klassenvariable, var camelCase = new CamelCase(); . Ich glaube jedoch nicht, dass dies ein Problem darstellen würde, da Sie keine Klassen erstellen möchten, die nach Ihren Komponenten benannt sind.
3. Ich würde zustimmen, dass das Erstellen von zwei einzigartigen Ereignissen, die nur durch den Fall unterschieden werden, eine sehr schlechte Programmierung wäre.

Meine größte Sorge ist es, seltsame Inkonsistenzen mit der Art und Weise einzuführen, wie Menschen codieren. Beispielsweise sind alle gültig und identisch: :myprop="" :myProp="" :mYpRoP="" :my-prop="" .

👎 Kebab-Fall im Markup und Kamel-Fall im Code beibehalten. Es ist Teil der HTML-Spezifikation und das Ignorieren der Groß-/Kleinschreibung wird eine größere Lernkurve für diejenigen sein, die von anderen Frameworks kommen oder den Standard bereits gelernt haben.

Ich stimme @Teevio zu, Konsistenz wird verloren gehen

HTML verwendet Kebab-Case und es ist ein anerkannter Community-Standard, dass ECMAScript eine CamelCase-Sprache ist. Wir sollten sie getrennt halten, anstatt sie zu _verstecken_ (In der Reaktion können Sie nur über data-* & aria-* reagieren, um ein benutzerdefiniertes Attribut zu rendern, was die Konsistenz erzwingt).

Einem _Anfänger_ zu erklären, warum (z. B. über den MDN-Link oder sogar hier) camelCase <-> kebab-case, wird dem HTML-Verständnis des Anfängers sehr helfen.

Stimme Evan zu, Lesbarkeit und Codekonsistenz sind wichtiger!
+1

Für mich wird es wirklich seltsam aussehen, camelCase in HTML zu haben.

HTML ist HTML, JS ist JS

aktuelle Version ist in Ordnung

Nachdem ich Vue 6 Monate lang verwendet habe, erwischt mich das immer noch jedes Mal :( keine große Sache, da die Warnung für Vue so gut ist, dass ich weiß, was ich getan habe, aber ich kann die Idee hier voll und ganz verstehen und sie unterstützen +1

+1 Abwärtskompatibilität auch.

+1
Ich stimmte zu. Wir müssen die Abwärtskompatibilität beibehalten.

Ist es sinnvoll, alle Ereignisnamen in Kleinbuchstaben zu normalisieren?

Ich stimme @azamat-sharapov zu

@Teevio Vue-Komponenten sind ungefähr Klassen: Wenn Sie var MyComp = Vue.extend({ .. }) ausführen, können Sie anschließend var myComp = new MyComp() ausführen. Das Problem mit der mehrfach gültigen Syntax existiert bereits: :my-prop , :MY-PROP und :mY-pRop funktionieren ab sofort alle gleich, da HTML einfach alle Fallinformationen wegwirft. Mit dem vorgeschlagenen Feature ist es nicht viel anders. Wie bei allen Stilargumenten geht es darum, einen Stil auszuwählen und dabei zu bleiben.

Re @jamesxv7 @moe-szyslak @jonagoldman und andere, die Bedenken haben, sich vom HTML-Standard zu entfernen: Es ist absolut zulässig, camelCase-Tags/Attribute in HTML zu schreiben, es ist nur der Tag/Attribut-Namensabgleich wird ohne Berücksichtigung der Groß-/Kleinschreibung durchgeführt . Das sagt die Spezifikation :

In Dokumenten in der HTML-Syntax:

Tag-Namen für HTML-Elemente können mit einer beliebigen Mischung aus Klein- und Großbuchstaben geschrieben werden, die eine Übereinstimmung ohne Berücksichtigung der Groß-/Kleinschreibung mit den Namen der Elemente darstellen, die im Abschnitt „HTML-Elemente“ dieses Dokuments angegeben sind. Das heißt, bei Tag-Namen wird die Groß-/Kleinschreibung nicht beachtet.
Attributnamen für HTML-Elemente können mit einer beliebigen Mischung aus Klein- und Großbuchstaben geschrieben werden, die eine Übereinstimmung ohne Berücksichtigung der Groß- und Kleinschreibung mit den Namen der Attribute darstellen, die im Abschnitt HTML-Elemente dieses Dokuments angegeben sind. Das heißt, bei Attributnamen wird die Groß-/Kleinschreibung nicht beachtet.

Wenn also die Verwendung von PascalCase/camelCase die Codekonsistenz/Lesbarkeit verbessert, ist dies vollständig spezifikationskonform. Dies ist vielleicht nicht jedermanns Sache, aber wenn Sie eine Kebab-Hülle bevorzugen, können Sie diese weiterhin verwenden.

Und insbesondere zu @jamesxv7 : Dies unterscheidet sich von dem, was Angular 2 tut. Angular 2 unterscheidet bei seinen Templates zwischen Groß- und Kleinschreibung, indem es einen benutzerdefinierten HTML-Parser einführt. Im Gegenteil, Vue folgt tatsächlich der Spezifikation, indem es die JS-Gegenstücke unabhängig von Groß- und Kleinschreibung macht.

Ich ziehe es vor, Kebab in HTML zu halten. Ich mag die Idee der Konsistenz, aber ich mag die Idee der Spezifikationskonformität mehr.

CamelCase-Tag gefunden:. Bei HTML wird die Groß-/Kleinschreibung nicht beachtet. Benutzenstattdessen. Vue gleicht es automatisch mit Komponenten ab, die mit camelCase-IDs in JavaScript definiert sind.

Diese Warnung ist bereits ziemlich prägnant, wie die Komponentenregistrierung funktioniert. Abgesehen davon, wie andere bereits erwähnt haben, denke ich, dass es großartig ist, camelCase in HTML zuzulassen, solange es noch die Möglichkeit gibt, weiterhin Kebab zu schreiben.

@yyx990803 Ja , einverstanden. Ich versuche nur, so viele Argumente wie möglich dagegen zu finden, aber ehrlich gesagt habe ich keine, die greifen würden. Wie Sie bereits erwähnt haben, streiten wir letztendlich über stilistische Entscheidungen. Ich persönlich denke, dass ich mit den erwähnten Änderungen einverstanden bin, solange wir bei dem bleiben können, was wir bereits haben, während wir die Möglichkeit haben, die neuen Sachen zu verwenden (aber nicht dazu gezwungen werden).

Wenn kebab-case immer noch funktioniert und die Verwendung von camelCase/ PascalCase eine Option ist, die BC nicht bricht, wenn ich sie verwende, dann kann ich nicht gegen die Hinzufügung sein. Es ist keine Veränderung, die mich dazu zwingt, etwas anderes zu tun. Es ist nur eine neue Option.

Das einzige, was ich sagen oder vorschlagen könnte, ist sicherzustellen, dass diese Option gut dokumentiert ist und - Gute Arbeit, wie immer, Evan!

Scott

Vielleicht können wir eine Option daraus machen: warnen oder ignorieren.
Angenommen, ich habe eine Komponente: myComponent
und ich bezeichne es in HTML als mycompOnent Ich persönlich würde eine Warnung bevorzugen, wie:
we found something that would match "myComponent": "mycompOnent" (line 152), use "my-component" instead
Dasselbe gilt natürlich für Requisiten.
Ich denke, spätere Lesbarkeit ist wichtiger als alles, was beim ersten Versuch funktioniert.

Ich bin auch auf Kebab-Case/CamelCase-Probleme gestoßen. Aber das eigentliche Problem war, dass ich keine Warnungen bekam, was falsch war ;)

Default könnte sein, dass es keine Warnung gibt und es einfach funktioniert, das ist für mich irrelevant.
Auch die Warnungen sollten meiner Meinung nach nur im Debug-Modus sichtbar sein

Was ist mit Dingen wie atone vs. a-tone vs. at-one ? Ich stelle mir jedoch vor, dass sie ziemlich seltene Vorkommnisse sind.

@simplesmiler- Kebab-Requisiten würden immer noch mit der Groß-/Kleinschreibung nach alten Regeln abgeglichen.

Dies fördert keine Transparenz gegenüber Webstandards. Die Spezifikation für benutzerdefinierte Elemente besagt, dass Namen einen Bindestrich enthalten sollten: <my-component/>

Was ist mit dem, was @simplesmiler sagte: addOne und adDone würden denselben Code ausführen. Besonders fies wäre dies bei der Umsetzung für Events,

Und da HTML die Groß-/Kleinschreibung nicht beachtet, wollen wir die Idee der Groß- und Kleinschreibung nicht aus der Bibliothek einführen. Diese Implementierung würde nur die Groß- und Kleinschreibung in HTML fördern, was meiner Meinung nach eine schlechte Idee ist.

Außerdem verwenden wir Bindestrichtrennung in Dateinamen. Sollten wir sie auch dort entfernen und mit dem Hinzufügen von Hüllen beginnen?

Zu guter Letzt: Die Koexistenz des Hypen- und Casing-Systems fördert unterschiedliche Codierungsstile für neue Entwickler in einem Team.

Ich bevorzuge den Ansatz von @paulpflug ; Richtige Warnungen in diesem Bereich würden sehr helfen.

Ich bin kein Fan davon, den HTML-Pascal/Camel-Fall zu machen. Es bricht Webstandards, ich weiß, es ist schön, Konsistenz zu wahren.

Indem Sie versuchen, die Dinge ein wenig konsistent zu machen, fügen Sie eine weitere Ebene der Komplexität hinzu. Es kann auch schlechte Praktiken verlockend sein. Eine Bibliothek sollte die Einhaltung der Standards fördern und Entwickler nicht irreführen, da sie eines Tages möglicherweise an einem Ort arbeiten müssen, an dem Vue nicht verwendet wird, was dazu führt, dass sie nicht verstehen, warum das HTML anders geparst wird.

Ich stimme @paulpflug voll und ganz zu: Das Hinzufügen einer Warnung bedeutet weniger Arbeit für den Produktionscode und bringt Entwickler wieder auf den richtigen Weg, um gültigen Code zu schreiben.

Ein gutes Argument dafür, warum dies nicht implementiert werden sollte: http://eisenbergeffect.bluespire.com/on-angular-2-and-html/

Dies ist häufig ein hervorgehobener Grund, warum Leute Angular 2 nicht mögen. Ich stimme voll und ganz zu, Bibliotheken standardkonform zu halten. Es wurde einmal für HTML entworfen, um die Groß- und Kleinschreibung zu beachten, und es wurde wegen zu vieler Probleme und der Eröffnung von Situationen mit zu großer Flexibilität verworfen.

@blake-newman: Diesbezüglich denke ich, dass @yyx990803 bereits in einem früheren Kommentar darüber gesprochen hat.

@jamesxv7 Dieser Kommentar fasst es ziemlich gut zusammen; Evan schlägt keine Änderung der HTML-Spezifikation vor, er schlägt vor, zu ändern, wie Vue Komponentennamen findet. Anstatt Kebab in Kamel umzuwandeln und die passende Komponente zu finden, würde es wahrscheinlich Bindestriche entfernen (um Kebab aufzunehmen) und dann Komponenten ohne Groß- und Kleinschreibung suchen. Der HTML-Code selbst bleibt weiterhin spezifikationskonform. Es würde uns auch erlauben, jeden Fall zu verwenden, den wir wollen. Das scheint mir keine schlechte oder schlechte Wahl zu sein :)

@yyx990803 Planen Sie, dass der <MyComponent> -Stil der beworbene Stil ist (dh Dokumente und Beispiele werden so geschrieben), oder wird es nur eine Option sein und der Kebab-Case-Stil bleibt der primäre Stil?

@blake-newman lies diesen Kommentar - er entspricht dem Standard :)

@paulpflug @guidobouman : Es gibt bereits Warnungen für camelCase-Tags und -Attribute, wenn Sie die neuesten Versionen von vue-loader oder vueify verwenden. Die camelCase-Prüfungen müssen jedoch zur Kompilierzeit durchgeführt werden, da die Fallinformationen aufgrund des Verhaltens des HTML-Parsers bereits zur Laufzeit verloren gegangen wären. Wenn Sie also Vue ohne vue-loader oder vueify verwenden, werden (und können) keine Warnungen angezeigt.

@yyx990803 - Aber die Spezifikation @blake-newman, die für Webkomponenten verlinkt ist, besagt Folgendes:

Der benutzerdefinierte Elementtyp identifiziert eine benutzerdefinierte Elementschnittstelle und ist eine Zeichenfolge, die mit der NCName-Produktion übereinstimmen muss, ein _U+002D HYPHEN-MINUS-Zeichen_ enthalten muss und _darf keine ASCII-Großbuchstaben enthalten_ .

Ich bin mir nur nicht sicher, wie sich das auf Vue-Komponenten bezieht. In der Dokumentation sagen Sie, Sie versuchen, dem Standard für Webkomponenten locker zu folgen.

Sie haben vielleicht bemerkt, dass Vue.js-Komponenten Custom Elements sehr ähnlich sind, die Teil der Web Components Spec sind. Tatsächlich ist die Komponentensyntax von Vue.js lose nach der Spezifikation modelliert.

Ich würde also sagen, dass die Spezifikation zuerst geändert werden muss, um camelCase und PascalCase zuzulassen.

Scott

@smolinari Die Vue-Dokumente sagen, dass es "locker modelliert" und nicht "streng" ist, und meiner Meinung nach lässt dies Raum für diese Änderung.

@yyx990803 Die Fallinformationen können verloren gehen, aber es könnte immer noch eine Warnung geben.
Wenn ich 'mycOmponent' in die Vorlage geschrieben habe, wird es zu mycomponent geparst, aber erwartet ist my-component , dann sollte Vue (im Debug-Modus) neben my-component nach mycomponent suchen my-component und warne mich vor der falschen Verwendung. Die verlorenen Fallinformationen spielen hier keine Rolle.
Es könnte eine Option geben, die Warnung zu unterdrücken und stattdessen direkt abzugleichen (entspricht Ihrem vorgeschlagenen Verhalten).

-1 zur Migration auf camelCase/PascalCase. Es wäre etwas verwirrend, eine JS-ähnliche Syntax in HTML zu sehen. Derselbe Grund, warum ich jsx nicht ausstehen kann.
+1 für den Vorschlag von @paulpflug . Wenn das Problem beim Onboarding von Anfängern liegt, warum geben Sie nicht einfach eine Warnung aus, die den Benutzer über das Problem informiert?

@paulpflug das klingt nach einer gültigen Idee!

Ich stimme zu, eine Warnung zu haben, die 'mycomponent' is missing, did you mean 'my-component'? sagt, fühlt sich besser an als eine stille Substitution.

@yyx990803 Ist es möglich, dies auf einer globalen Options-API zu tun?
z.B
Vue.config.kebab = true (standardmäßig) -> <my-component :my-prop="msg"></my-component>
Vue.config.kebab = false -> <MyComponent :myProp="msg"></MyComponent>

@yyx990803
Ich frage mich nur, was ist das Ideal, das wir anstreben?
wie @rpkilby sagte, <MyComponent myCustomProp="myProp" data-name="prop" aria-label="Close" onclick="myDialog.close()"> sieht komisch aus.

Im Wesentlichen besteht das Problem darin, dass js und html unterschiedliche Technologien sind und unterschiedliche Benennungssysteme verwenden. Und die Verwendung des gleichen Falls (Kebab oder Kamel) in beiden Technologien verschiebt die Verrücktheit von einem Ort zum anderen, aber das zugrunde liegende Problem bleibt bestehen
Ich glaube also, das Beste, was wir tun können, ist, eine Grenze zu ziehen. und die aktuelle Zeile i,e. Kebab Case im HTML-Kontext und CamleCase (und PascalCase) im JS-Kontext ist sehr gut .

Also meiner Meinung nach sollten wir nur aktuelle Konventionen unterstützen, anstatt nach einer besseren zu suchen. Und verwenden Sie natürlich eine Warnung, um Anfängern zu helfen

@prog-rajkamal ja, ich bin jetzt geneigt, die Warnung einfach umzusetzen.

Ich stimme jetzt :+1: dafür, auch nur die Warnung hinzuzufügen.

Scott

:+1: zum Hinzufügen einer Warnung

:+1: Auch für die Warnung

Geschlossen über ccf9bede6bc39fb62e43e1efe98136c5f35dae6b & d7b55c4ee8491dbd853e28a1527050d2d1e7deab

Eine Warnung wäre toll. Ich habe gerade eine Stunde damit verbracht, herauszufinden, warum auf mein benutzerdefiniertes Ereignis nicht reagiert wurde (die Antwort war, dass es einen Namen in Kamelbuchstaben hatte).

Es gibt eine Warnung, wenn Sie eine entsprechende Komponente oder Requisite haben, die auf die kebab-case -Version Ihrer PascalCase -Komponente oder -Requisite reagieren würde. Wenn Sie bei einer Veranstaltung einen Tippfehler machen, kann Vue nicht viel dagegen tun.

Oder meinst du für standardmäßig vorhandene Event-Requisiten wie v-on:keyup oder kurz @keyup ?

@guidobouman in meiner Vorlagendatei hatte ich <my-component v-on:customEvent="myMethod"> . In einer untergeordneten Komponente hatte ich this.$emit('customEvent'); . Das eigentliche Ereignis, das von den Eltern abgehört wird, ist natürlich customevent und nicht customEvent , aber ich habe Ewigkeiten gebraucht, um das herauszufinden, weil es nicht einfach zu debuggen ist. Ich dachte, es wäre gut gewesen, für vergessliche Leute wie mich zu warnen, dass ein Camel-Case-Attribut nicht als solches geparst würde. Vielleicht wurde dies bereits oben diskutiert, und wenn ja, entschuldige ich mich.

@anthonygore ist leider unmöglich, da der Browser HTML in Kleinbuchstaben konvertiert, bevor Vue darauf zugreifen kann.

Meine Frage ist, warum kann Vue es nicht für uns konvertieren? Warum müssen wir uns an die Kebab-Kiste erinnern

Die einzige Regel, die man sich merken sollte: HTML = kebab-case, JavaScript = camelCase

Mit HTML meine ich Attribute und Tags. Attributwerte sind JavaScript-Ausdrücke, wenn Sie v-bind verwenden, daher gilt die zweite Anweisung.

Meine Frage ist, warum kann Vue es nicht für uns konvertieren? Warum müssen wir uns in In-Vue-Dateien an Kebab-Fall erinnern? Es macht die Sache für Anfänger umständlicher ... Ich habe nur die letzten 20 Minuten dafür verschwendet ...

Verschwendete letzte 1,5 Stunden, weil ich es nicht einfach gegoogelt habe ... dxmn