Angular 2 bindings

[vincentp]

Hi,

I wanted to try to integrate Angular 2 to my Rails app, but I quickly ran into a problem.

The new binding syntax: https://angular.io/docs/ts/latest/guide/template-syntax.html#!#binding-syntax

Example:

button.btn.btn-primary type="submit" (click)="loadFolder()"

I can use the other option for now:

button.btn.btn-primary type="submit" on-click="loadFolder()"

But it would be nice to have both options. The round brackets around the (click) are breaking the templates, any plan to support that?

Thx!! :)

[bitterloa]

I agree. I really love Slim but just found that I may not be able to use it for Angular 2. In addition to using parenthesis as noted above, Angular 2 also uses the pound sign sometimes in tags as well, a la:

<md-sidenav #start mode="side" (click)="toggleNav()"></md-sidenav>

[lthomaz]

+1

[westonganger]

Rather than trying to get a grip on all this messing with new javascript html syntaxes, It would be convenient to have something we can wrap around the attributes so that they are not processed at all and just kept as is.

For example it could be something like this:

.my-item#custom-item{ #selectedItem *ngFor='item in items' (click)='selectItem()' }

(Note: I did not look to see if this syntax is already used for something else but you get the idea)

[chrisnicola]

I think @westonganger's solution is the most practical, essentially allow one of the outer brace choices for attributes be one that allows for literal and flexible attribute naming within.

Since I believe this causes an error now I'm hard pressed to come up with a practical example of where this might cause a breaking change. If absolutely necessary though it could be feature flagged until the next major version number.

[govorov]

Hi. According to documentation, it is possible to pass hash via *. So this code will work:

i.icon.long.arrow.left.link*{ '[(exp1)]' =>'test', '(exp2)' => 'test', '[exp3]' => 'test', '#exp4' => true }

compiles to

<i #exp4="" (exp2)="test" [(exp1)]="test" [exp3]="test" class="icon long arrow left link"></i>

Looks a bit ugly, but for now it's the only way.

[chrisnicola]

That's not too bad actually. At least it is an option. For now we are just using the SLIM safe attributes like bind-name and on-name that Angular provides. We are also considering whether or not it really makes sense to use SLIM templates with Angular at all.

However given that SLIM supports {} () and [] as delimiters it wouldn't be so bad for one of those, preferably {} for parsing simplicity, to support preserving [] and () in the attributes without quoting them or requiring hash rockets. In order to avoid any backwards compatibility issues I would suggest that an "Angular" mode switch be included that enables this.

It is worth noting Pug templates have a similar problem and ng2 style attributes must be quoted to work: https://pugjs.org/language/attributes.html.

[govorov]

I've just tested different slim configuration options. So, with this settings:

attr_list_delims: { '{'=>'}' }, code_attr_delims: { '{'=>'}' }

It is pottible to write this code:

h1{ #var (bind1)="test" [bind2]="ok" [(bind3)]="works?" } it works

Compiled result is:

<h1 #var="" (bind1)="test" [bind2]="ok" [(bind3)]="works?">
    it works
</h1>

Looks like works everything, but *ngIf and others with asterisk.

[govorov]

Looks like I found a working solution.
First - set attr delimeters to curly braces only. And then patch original parser.rb to change splat attributes syntax, because it causes confilcts with *ngIf and others.
https://github.com/govorov/slim/tree/angular2

So, this code works:

  h1{ #var (bind1)="test" [bind2]="ok" [(bind3)]="works?" *ngIf="expr" *ngFor="expression" } {{it works}}

Compiled result:

  <h1 #var="" (bind1)="test" [bind2]="ok" [(bind3)]="works?" *ngIf="expr" *ngFor="expression">
    {{it works}}
  </h1>

UPD: added configuration option for splat attributes regexp. Original value is /\A\s*\*(?=[^\s]+)/. New default is /\A\s*\*\*(?=[^\s]+)/

[chrisnicola]

Awesome now to try this with slm-lang as well

[minad]

It seems we can handle this without breaking changes, see #739. I am looking forward to support this if someone is willing to write the necessary patch.

[govorov]

I have commited required changes in #739
What about to merge it in upstream?

[minad]

Hi, thx for the patch. Unfortunately it is not as simple as that. The patch is not ready to be merged for the following reasons and I don't have the time to fix it myself.

• We need test cases for the new option
• I would like the option to just be a string instead of a regex (as mentioned before)
• The regex should be generated in the constructor
• Documentation is not at the right place
• Option table in the documentation should be updated
• The changelog wasn't updated

If you have time to work on those issues it would be great.

[govorov]

Hi. Made some updates in #739. Looks like everything but changelog from list above is completed.
Thanks in advance.

[minad]

It is ok to close this one?