RFC: <proposal #someId [bind]="expr" (event)="doWork()">

[mhevery]

Update from @IgorMinar on 2014-11-10:

To summarize the constraints, the solution we are looking for must match the following:

1. Be valid HTML (see this issue for discussion about [, ], (, ) chars in attr name of valid html).
2. Be Web designer friendly
3. Interoperable with web-components (don't interfere with web component initialization)
4. Support debugging story via inspecting rendered DOM during development
5. The syntax must clearly distinguish between 1) string literal; 2) expression (binding); 3) expression (events) 4) declaration of variables. All of this must be clear from template without understanding which directives are active or what the internal semantics of these directives are.
6. Support additional info or options for each binding in order to avoid directive specific micro-syntaxes (this enables for tooling to work without hardcoding support for micro-syntaxes). This must be supported in a way that preserves constraint no. 5.

Please don't propose any new solutions that don't meet all of the criteria above.

---

Original description:

Current proposal for Angular2 syntax is

<element #someId [bind]="expr" (event)="doWork()">

There are several issues with this proposal which have come to light recently. These are:

element.setAttribute('[foo]', 'exp') does not work.

In all browsers tested (Chrome, IE, Safari) the above is an error. This means that it is not possible to create a valid template programatically. It is still possible to parse and read the template.

It seems like that calling setAttribute requires first character to be a-z|_ specifically - is not allowed as starting character nor are any of these ~!@#$%^&*(){}.

Third part HTML shorteners don't support non-standard characters.

Tools such as Slim, Haml, JADE don't support generating special characters. This would break the backend servers such as Ruby on Rails.

SVG requires valid XML and []()# is not valid XML.

This seems to be in the spec, but at least Chrome browser does not have issues with these characters. Need to investigate more.

Straw-man Proposal

We go back to slightly longer text based syntax

<element var="someId" bind-value="expr" on-event="doWork()">

The caveat is the ng-repeat syntax, which requires a parameter

<ul>
  <li bind-ng-repeat--item="items">{{item}}</li>
</ul>

Why the weird ng-repeat syntax? We want ta make sure that all bindings starting with bind- have right hand side as a valid expression. item in items is not a valid expression, it is a micro syntax. For this reason we need a way to pass the local-var-name into ng-repeat as a string literal, and not as an expression. Hence the ng-repeat--<local-var-name-literral>="expression".

Please leave your thoughts here.

Background

The reasoning behind the new syntax can be found here: https://docs.google.com/document/d/1kpuR512G1b0D8egl9245OHaG0cFh0ST0ekhD_g8sxtI/edit#heading=h.xgjl2srtytjt

[SanderElias]

I do prefer the readability of the current proposal. The setAttribute issue can be worked around.
Dropped into the console, and did some testing. I came up with this:

   function addAttribute(element, attrName, attrValue) {
      var tmpElm = document.createElement('p');
      tmpElm.innerHTML = "<p " + attrName + "='"+attrValue+"'><p>";
      var newAttr = tmpElm.children[0].attributes[0].cloneNode(true);
      element.setAttributeNode(newAttr);
   }

Witch is pretty rough, but I checked, and it does comply to all W3C standards. Well except for enabling attributes with 'exotic' names.

And with the straw-man proposal, if a user wants to create his own ngRepeat, how would that be possible?

[mprobst]

FYI for a JavaScript renamer like JSCompiler, the ng-repeat--item="items" would be easier to grok with ng-repeat="item in items". If you rename the subsequent use-sites of item, you also have to do so for the declaration. I think if you don't want microsyntaxes, you'll most likely have to go with additional attributes (ng-repeat="items" ng-repeat-var="item", could default to $item or so).

[0x-r4bbit]

@SanderElias I think there are a couple of problems with that snippet:

• It requires to work with strings and .innerHTML which leads to xss vulnerabilities. Which is also why angular works with DOM elements instead of strings because we get xss security by default
• I'm not sure if the order of attributes is defined, which means you can't really rely on .attributes[0].cloneNode(true);. If there's more than one attribute, you might get some ugly side effects.
• All in all it feels more like a hack

I like the bind-* and on-* syntax much more (also because I got used to it when reading all the design documents). @mhevery is the caveat with ng-repeat the only reason why you first decided to use [] and () over bind-* and on-* ?

[caitp]

if all of the angry tweets and blogs are to mean anything at all, it seems people don't want a new syntax anyways. easier for them if it's as similar as possible to before.

[SanderElias]

@PascalPrecht, Sure it feels like a hack, because it is one. I whipped up the snippet in a couple of minutes to show a way around the limitation of element.setAttribute(). And you can be sure on the order of attributes if you create the html-snippet under the functions control. If something like this ends up in the source, it sure needs to check the strings for XSS attacks.

@caitp creating new paths always can count on resistance. On my part, the jury is still out on this one.

[caitp]

the question is, what do we get out of the "new paths", if it's just change for the sake of change then it's not really doing any good. even though the grammar is technically easier to write parsers for, tools have been writing parsers for and working with angular expressions for a while now, so it seems like a moot point.

I'm really not sure we're getting any kind of "win" by making these changes.

[caitp]

Unless we can demonstrate that it's really easier for people to use, then I would say don't even bother with it

[SanderElias]

@caitp Hmm, to me the win is better readable templates, and less boilerplate. The parser argument is indeed no reason whatsoever in this case. However, if the parser gets more then a few % slower as a result of the straw-man proposal, it is an valid point.

[0x-r4bbit]

I'm still interested in what causes the original decision to use [] and (). There are four proposed syntaxes for template bindings but there's no official discussion on why the team decided to use [] and () over bind-* and on-*, or even one of the other two. Does anybody know why that is?

[otodockal]

on-* syntax looks much more natural to use, it's similar to DOM events syntax and the current ng-event syntax.

[akircher]

Must you have a different left-hand syntax for binding and events?
Every event handler I have seen is a function call that contains a '()'. If Angular2 enforces this natural limitation that event handlers must be functions ( searching for a '(' and a ')' on the right-hand side), then you could use the same syntax for both binding and event. Two possibilities are:

<proposal ng-id="someId" ng-bind="expr" ng-event="doWork()">

<proposal _id="someId" _bind="expr" _event="doWork()">

As for ng-repeat, no novel ideas. I think that the bubble up event syntax (^click) will also need a work around for these problems. I would just try to keep the syntax as close to javascript as possible.

<ul>
  <li ng-for="let item of items">{{item}}</li>
</ul>

[0x-r4bbit]

@akircher yes there is a reason why angular needs a new binding syntax. In order to work with any elements (that means native and custom) a new syntax is required that unifies the layer. Angular doesn't and shouldn't know about custom elements (or custom events). I've written an article about that which tries to explain it (http://pascalprecht.github.io/2014/10/25/integrating-web-components-with-angularjs/).

[sheerun]

Hey! I paste my proposal from Google Gruups with syntax that resolves custom elements problem and doesn't break HTML attributes.

I've seen Angular plans to adopt following syntax for data binding:

<web-component [title]="exp" (close)="exp()">

Please don't break HTML syntax :( I love Angular because I can write templates for it in any templating language like SLIM or HAML or Jade (you can't do it in Ember or React, for example). Introducing non-standard characters in attributes makes templating languages unusable (as well as syntax coloring and introspection in IDE).

Also, I really don't like this syntax for passing arguments [ng-repeat|person]="people"

• for me it's not clear what it does
• it allows for passing only string arguments
• both "person" and "people" are arguments to ng-repeat. Why to treat one differently?
• it severely breaks existing syntax that developers are used to

I propose to use _ prefix for properties that need to be processed by Angular first. Then, use microsyntax instead of ugly [ng-repeat|parameter] syntax to provide parameters.

<web-component
    _string-parameter="Hello world"
    _fancy-string-parameter="Hello ${exp}"
    _one-way-bind=":exp"
    _two-way-bind=".exp"
    _on-click="exp()"
    _ng-repeat=".person in :people"
    _ng-if=".isVisible">

There are many advantages of such syntax:

1. You don't break HTML syntax, most IDE and templating languages support leading _
2. Attribute names only tell whether pass binding to Angular or not. Exact meaning is determined by Angular or its plugin.
3. "templating system should be conflated with the binding system"
4. Contrary to your current choice this syntax is extensible, and plugins can implement their own microsyntaxes.
5. It allows for seamless WebComponent integration, as _ prefixed properties are handles by Angular before they are renamed and passed to WebComponent.
6. I think it's lot more pleasurable to read and understand

All to all, my proposal is:

1. Angular processes only properties beginning with _
2. Angular supports out of the box following microsyntaxes:
   • exp - string interpolation (default, can include ES6 interpolation syntax ${exp})
   • exp() - javascript expression (like _on-click="exp()")
   • :exp - one way bind (familiar syntax!)
   • .exp - two way bind (natural syntax too)
   • exp1 in exp2 - special syntax for _ng-repeat, exp1 and exp2 are re-interpreted as microsyntaxes
3. Plugins and future versions of Angular can define their own microsyntaxes.

Did I miss something? I beg you to consider this. I really love Angular 2.0 decisions so far, except for binding syntax.

Few additional notes:

1. I wanted javascript expression to be the default, but I think it should be string interpolation. The same way HTML treats all attibute values as strings by default. So for example _type="text" means literally type="text", but _type=".inputType" does double binding, and _type="inputType()" evaluates an expression.
2. This syntax also makes distinction between one-way and two-way binding. Your current choice doesn't.
3. Plugins could create microsyntaxes from existing ones, similar to _ng-repeat's "exp1 in exp2" syntax.
4. Such syntax is really "pluggable" and fast. Angular only reads properties beginning with _ and passes them through "middleware" set of functions with interface like call(e: HTMLElement, attribute: string, value: string).

[sheerun]

Of course if for some reason Web Component uses _property, you can use __property in template.

p.s. code fragments were missing from my previous comment. they are present now.

[akircher]

@PascalPrecht I understand that Angular2 needs a generic binding/event handling syntax in order handle custom events from web components. Am I missing something else from your post? (very helpful btw)

But what I am saying is that the parser could take

<proposal ng-id="someId" ng-bind="expr" ng-event="doWork()">

and seeing that expr doesn't have a '()' and that doWork does have a '()' could rewrite this to

<proposal ng-id="someId" bind-bind="expr" on-event="doWork()">