Angular 2: Ist die Verwendung von Klammern/eckigen Klammern obligatorisch?

Question

In den bislang veröffentlichten Angular 2 -Voransichten wurde die Syntax des Markups von ng- Präfixen in eckige Klammern und eckige Klammern geändert.

Während vor einem habe:

<input ng-model="userName" /> 
<button ng-click="btnClick()">Run</button> 

Die neue Syntax ist:

<input [value]="userName" /> 
<button (click)="btnClick()">Run</button> 

Weiß jemand, ob diese Syntax ist/wird obligatorisch sein, und ohne Alternativen?

Wir haben derzeit eine Anwendung, in der der HTML-Code über XSLT generiert wird, und [ und ( sind keine gültigen Attribute - daher kann keine Angular 2 JS-Syntax generiert werden.

Answer 1

Nicht zwingend: -

http://eisenbergeffect.bluespire.com/all-about-angular-2-0/

Bitte Kasse den Abschnitt Richtlinien (in der Nähe von etwa in der Mitte der Seite): - Die „Decorator-Richtlinie“ ist immer noch da, was im Hinblick bedeutet auf Ihre Frage.

Es wird sicherlich einen Rückfall geben.

die offiziellen demostration Do Kasse als auch, ng-Modell/Klick wird, dass auch verwendet: -

https://www.youtube.com/watch?v=gNmWybAyBHI

Answer 2

In der Tat, [] und ()sind gültige HTML-Zeichen in Attributen. Wenn Sie HTML-Code serverseitig generieren oder einen anderen Präprozessor verwenden, der diese Zeichen nicht verarbeiten kann, können Sie immer die entsprechende kanonische Syntax verwenden.

• [] ist eine Abkürzung für bind-*, daher [propertyName] == bind-property-name
• () eine Abkürzung für on-*, daher (eventName) == on-event-name

Diese Syntax verwendet wird, hauptsächlich aus zwei Gründen (und tatsächlich zwingend):

• Escaping - Elementattribute müssen maskiert werden. Wenn Sie ein Image-Tag mit einem dynamischen src wie folgt haben: <img src="{{imageSource}}"> würde dies zu einem 404 Fehler führen, da der Browser sofort versucht, die angegebene URL anzufordern. Die URL in diesem bestimmten Moment ist {{imageSource}}, was sicher keine gültige URL ist. Daher haben wir das Attribut ngSrc in Angular 1. Wir können es wie <img ng-src="{{imageSource}}"> verwenden. Was es tut ist, es wartet, bis die Interpolation ausgewertet wird und dann fügt ein src Attribut das Bild hinzu. Dies stellt sicher, dass aufgrund einer asynchronen Interpolationsauswertung keine falsche Anforderung gestellt wird. Es gibt ein paar mehr Direktiven, die dabei helfen, wie ng-href. Wenn es um Webkomponenten geht, sind Attributnamen nicht mehr deterministisch.Web-Komponenten können ihre eigenen Attribute definieren, von denen das Framework nichts weiß. Wir haben also zwei Möglichkeiten: Wir erstellen entweder eine Direktive für jedes Attribut, das es zu entkommen gilt (oh nein!), Oder wir entwickeln eine allgemeinere Syntax, die Angular versteht und die das Framework entsprechend abfängt. Deshalb wurde [propertyName] eingeführt. Auch dies ist nur eine Abkürzung. Verwenden Sie die kanonische Syntax, wenn diese Ihnen nicht entspricht.
• Eigenschaft Bindung - Jetzt können Sie sich fragen, warum [propertyName] und nicht [attributeName]. Es stellt sich heraus, dass wir auf ein anderes Problem gestoßen sind, wenn wir mit benutzerdefinierten Elementen arbeiten, die den Richtlinienzyklus von Angular nicht kennen. In Angular können wir entscheiden, wie ein Wert an den Bereich eines Elements gebunden ist. Also in diesem Code: <my-directive foo="bar">, bar könnte entweder nur Zeichenfolge oder ein Objekt sein, das zwei-Wege-Daten gebunden ist. Das wissen wir nur, wenn wir uns mit der Umsetzung der Richtlinie befassen. Webkomponenten und benutzerdefinierte Elemente kennen den Lebenszyklus von Angular jedoch einfach nicht. Das bedeutet, ein Attributwert ist immer eine Zeichenkette, denn das ist ein Attribut in HTML. Um sicherzustellen, dass wir immer noch andere Werte als nur Strings an ein beliebiges Element übergeben können, bindet Angular 2 an Elementeigenschaften statt an Attribute. Weil eine Eigenschaft eines Objekts eines DOM-Elements alles sein kann, nicht nur eine Zeichenfolge. Mit der Syntax teilen wir Angular mit, dass wir an die Eigenschaft des Elements binden wollen, nicht an sein Attribut. Dies bedeutet auch, dass nun der Konsument einer Richtlinie/Element/Webkomponente entscheidet, wie ein Wert an ihn übergeben wird.

Ich habe ein article darüber geschrieben, dass dieses Thema behandelt, auch ein Vortrag von ngeurope gibt.

Ich hoffe, dass dies die Dinge aufklärt!