Adding support for javascript expressions or statements in data bindings like in QML.
Not just function calls eg:
<my-elem>[[_myConcat(myAttr1, " - ", myAttr2)]]</my-elem>
But also valid js statements, therefore you don't have to create every function on your element class eg:
<my-elem>[[myAttr1 + " - " + myAttr2]]</my-elem>
or:
<button style="display: [[_isAdminDisplayBlockOrNone(isAdmin)]];">Admin login</button>
to:
<button style='display: [[isAdmin ? "block" : "none"]];'>Admin login</button>
Also adding support for using builtin js objects like Math and Date. And calling global functions eg:
<lint rel="import" href="an3thPartyLibrary.html">
...
<template>
<div>[[an3thPartyFunction(myAttr)]]</div>
</template>
This would simplify the elements interface and the speed of coding.
The implementation wouldn't be difficult, because polymer data bindings is already watching the change events on attributes, but now it would instead of calling the function, call eval on the entire expression.
This used to be supported as of 0.5 but was removed intentionally due to performance issues, caused mostly by parsing data bindings in runtime AFAIK. Another reason is that having too much logic in templates is not a good idea. Personally, I took part in migration of a big project from 0.5 to 1.x and I once missed a part of a VERY long line having multiple ternary operators like so, huh.
There is a polymer-expressions repo though, which has a 2.0-preview branch and might be used as an optional mixin in the future, at least as I remember from the conversation with @justinfagnani
The Polymer Expressions repo has now been archived. are there any new initiatives or thoughts on this request? I agree that we shouldn't have too much logic in templates but it seems overly-restrictive to completely disallow simple JavaScript expressions and results in an anti-pattern of having to create trivial functions that only have a single usage.
The best way to include JavaScript-like expressions in templates is to just use JavaScript, and not ship a custom expression parser and evaluator to the client. This is the direction we're going with lit-html and LitElement. It's a lot faster and more lightweight than Polymer + polymer-expressions.
Since we're not going to change Polymer's expression system, I'll close this now.
Most helpful comment
This used to be supported as of 0.5 but was removed intentionally due to performance issues, caused mostly by parsing data bindings in runtime AFAIK. Another reason is that having too much logic in templates is not a good idea. Personally, I took part in migration of a big project from 0.5 to 1.x and I once missed a part of a VERY long line having multiple ternary operators like so, huh.
There is a polymer-expressions repo though, which has a
2.0-previewbranch and might be used as an optional mixin in the future, at least as I remember from the conversation with @justinfagnani