Alternate binding syntax

[justinbmeyer]

• - Implement and test functionality, release it in new can-stache-bindings.

• - Add documentation for it

• - Make a code-mod.

• - Update CanJS guides and recipes to use it (will require CanJS pre release)

• - Make a release for this and canjs, push out new site.

• - Update DoneJS examples to use it.

• - deprecate old functionality.

New users can't remember our binding syntaxes. So, I propose we fix them asap. A 2 week sprint to create this and update the docs will make a 10% better CanJS.

Here's an alternate:

<!-- events ($click) -->
<div on:click="method()"/>

<!-- one-way scope to element property {$value}="scopeValue" -->
<input value:from="scopeValue"/>

<!-- one way element property to scope {^$value}="scopeValue" -->
<input value:to="scopeValue"/>

<!-- two-way element property to scope ({$value})="scopeValue" -->
<input value:bind="scopeValue"/>

I think the bindings above will work great for can-element which will have everything on the elements. There will be no need for "view model" bindings.

However, to enable this to work for view model bindings, I'll make two proposals:

1. Use vm to signal that behavior on a view model

<!-- events (close) -->
<my-element vm:on:close="method()"/>

<!-- one-way scope to element property {$value}="scopeValue" -->
<input vm:value:from="scopeValue"/>

<!-- one way element property to scope {^$value}="scopeValue" -->
<input vm:value:to="scopeValue"/>

<!-- two-way element property to scope ({$value})="scopeValue" -->
<input vm:value:bind="scopeValue"/>

2. Use the vm if you have one.

99% of the time, if you are on a custom element, you want a vm binding. So the bindings would check if there is a vm and use that, resulting in:

<!-- events (close) -->
<my-element on:close="method()"/>

<!-- one-way scope to element property {$value}="scopeValue" -->
<input value:from="scopeValue"/>

<!-- one way element property to scope {^$value}="scopeValue" -->
<input value:to="scopeValue"/>

<!-- two-way element property to scope ({$value})="scopeValue" -->
<input value:bind="scopeValue"/>

Cool stuff

This might be able to solve some other issues nicely like #6.

<input on:enter:value:to="scopeValue"/>

This would update scopeValue on the enter event with input.value instead of on the change event.

Other consideration

We now support events like:

<div (person born)="animate"/>

What would this look like in the new syntax?

<div on:born:by:person="animate"/> <-- favorite -->

<div on:born:for:person="animate"/>
<div on:person:born="animate"/>

<div for:person:on:born="animate"/>

<div on-person's-born="animate"/> <!-- I don't think this is possible, but would be cool -->

[marshallswain]

This whole thing is beautiful. For the <div (person born)="animate" /> scenario, it would be nice if we could make both of these options work:

<div on-born-for-person="animate"/>

<div for-person-on-born="animate"/>

So that it doesn't matter which order the for-x and on-x directives are used.

[justinbmeyer]

@nlundquist suggested using : which I now favor:

<!-- events ($click) -->
<div on:click="method()"/>

<!-- one-way scope to element property {$value}="scopeValue" -->
<input value:from="scopeValue"/>

<!-- one way element property to scope {^$value}="scopeValue" -->
<input value:to="scopeValue"/>

<!-- two-way element property to scope ({$value})="scopeValue" -->
<input value:bind="scopeValue"/>

[marshallswain]

That's even better!

And would camelCased variables be supported by hyphenation?

[justinbmeyer]

@marshallswain yes, but even without because can-view-parser will "escape" them for you:

<my-component someProperty:to="scopeValue"/>

<my-component some\cproperty:to="scopeValue"/>

[leoj3n]

I think :from, :to, and :bind make a lot more sense than {}, {^}, and ({}).

[pmgmendes]

For sure this will improve binding syntax readability too.
Would it be retro compatible with the current syntax?

[jeroencornelissen]

Love the idea and will improve readability!

[bmomberger-bitovi]

someProperty<="scopeValue" and childProp=>"parentProp" and twoWayProp<=>"parentTwoWayProp" would be so awesome but likely wouldn't work for obvious reasons.

[phillipskevin]

@pmgmendes the plan is to support this alongside the current syntax, so you could use either one.

[bmomberger-bitovi]

Are we sure that colon-syntax isn't going to interfere with the (probably rare except maybe for SVGs) edge case where someone uses namespaced attributes? Or rather, could @justinbmeyer comment on what it looks like with namespaces?

[justinbmeyer]

I don't think it will interfere with any svg namespaced attributes. I think you have to use setAttributeNS anyway. We currently don't allow specifying namespaces via stache. This could be a problem if we wanted to support that. I don't think it's needed.

[justinbmeyer]

@bmomberger-bitovi perhaps with can-parse we could "transpile" that to these new syntaxes. Your suggestion was similar to my original new binding syntax proposal:

foo{="bar"  bar}="foo"  {zed}="ted"  

[bmomberger-bitovi]

I had considered pretty much exactly that syntax, though I was thinking that if we can parse it, {= and =} and {=} might make more sense.

[phillipskevin]

@James0x57 put together the regular expressions we can use to codemod to the new binding syntax: #264 (comment) when the time comes.

[phillipskevin]

Created new issues for the last 2 tasks - going to close this.