Vorlagenzeichenfolge als Objekteigenschaftsname


79

Warum lässt JavaScript eine Vorlagenzeichenfolge nicht als Objekteigenschaftsschlüssel zu? Zum Beispiel, wenn ich Folgendes eingebe:

foo = {`bar`: 'baz'}

In die NodeJS REPL wird eine SyntaxErrormit "Unerwartete Vorlagenzeichenfolge" mit einer langen Stapelverfolgung ausgelöst. Eigenschaftswerte sind jedoch in Ordnung, was nicht so unerwartet ist. Ähnliche Fehler treten im Browser auf, z. B. löst Firebug eine SyntaxErrormit "ungültiger Eigenschafts-ID" aus.

Vorlagenzeichenfolgen sind in "berechneten Eigenschaftsnamen" zulässig. Dies lässt sich beispielsweise in allen Browsern, die die Syntax unterstützen, einwandfrei kompilieren:

var foo = {
    [`bar` + 1]: `baz`
};

und erstellt das Objekt {"bar1": "baz"}.

Warum sind Vorlagenzeichenfolgen nicht als Literalobjektschlüssel zulässig? Ist es aus Leistungsgründen? Vorlagenzeichenfolgen müssen möglicherweise zur Laufzeit kompiliert werden (korrigieren Sie mich, wenn ich falsch liege). Dies bedeutet, dass der Interpreter jedes Mal, wenn er auf dieses Objekt trifft, den Objektnamen berechnen muss. Unter Berücksichtigung von Dingen wie "gekochten" Template-Strings scheint dies langsam zu werden, obwohl wir seit ES5 Getter und Setter haben. Firefox erwähnt dies nicht als Fehler, weshalb ich es unerwartet fand. Wird die Syntax irgendwann in der Zukunft erlaubt sein?


2
Ist das nicht der Grund, warum berechnete Eigenschaftsnamen eingeführt werden? Ja, Sie benötigen geschweifte Klammern, aber es scheint auch syntaktisch besser als generische Lösung für verschiedene Szenarien.
Praveen Apulien

Ich überdenke nur meine Antwort und bin mir nicht sicher, ob sie richtig war. Jetzt stöbere ich in den ES6-Dokumenten ...
Max

Warum sind Vorlagenzeichenfolgen nicht als Literalobjektschlüssel zulässig? Sie sind, Sie haben nur die falsche Syntax ...?
Mathletics

Antworten:


70

Warum sind Vorlagenzeichenfolgen nicht als Literalobjektschlüssel zulässig?

Vorlagenzeichenfolgen sind Ausdrücke, keine Literale 1 . Sie können Zeichenfolgenliterale (und Bezeichner) nur für Eigenschaftsnamen verwenden. Für alles andere - von dem nicht bekannt ist, dass es statisch ist - benötigen Sie einen berechneten Eigenschaftsnamen.

Ist es aus Leistungsgründen?

Nein, das ist unwahrscheinlich. Dies erleichtert das Parsen und macht es einfach, konstante (statisch bekannte) Eigenschaftsnamen von dynamisch berechneten zu unterscheiden.

Und meistens ist es eine Funktion, die niemand braucht. Es vereinfacht oder verkürzt nichts, und was Sie damit erreichen würden, ist bereits möglich.

Wird die Syntax irgendwann in der Zukunft erlaubt sein?

Nee.

1: Selbst wenn sie "Vorlagenliterale" genannt werden, sind sie technisch gesehen keine Literale . Und: Vorlagen müssen nicht einmal Zeichenfolgen sein, sie können zu allem ausgewertet werden.


2
Was ist mit `var obj = {` $ {dyanmicKey} `: val}`?
b4d4r

77
@ b4d4r: Nein - Sie müssen berechnete Eigenschaften verwenden. Entweder var obj = {[`${dyanmicKey}`]: val}oder nur var obj = {[dyanmicKey]: val}.
Bergi

Mann, warum nicht? Sie wollen einfach nicht, dass die Leute dort Ausdrücke
einfügen,

@Bergi Wie würde man folgendes beheben:profile.preferences.networks[${network.name}]
basickarl

1
@SafalPillai Nicht in einem nicht zitierten Bezeichnernamen, aber {"#key": "value"}völlig in Ordnung.
Bergi
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.