Polymer: Support for expressions and filters

[tam4s]

These things below should work, because adding a full element with script tag in order to make simple things work prevents adoption of Polymer.

<template>
  1 + 1: <span>{{ 1+1 }}</span>
  Hello <span>{{ "world".toUpperCase() }}</span>
  ...or...
  Hello <span>{{ "world"|toUpperCase }}</span>
</template>

[ghost]

That is still not possible, what you can do is alter the binding with computed bindings: https://www.polymer-project.org/1.0/docs/devguide/data-binding.html#annotated-computed

[robdodson]

@tam4s you can do <template is="dom-bind"> to automatically stamp out a template, however Polymer 1.0 does not currently have support for binding expressions.

adding a full element with script tag in order to make simple things work prevents adoption of Polymer.

Polymer is designed for building Web Components, it's not primarily focused on being a general purpose templating library.

[sorvell]

Rob's comment covers Polymer's current behavior. We consider new features based on user feedback. Thanks for your comments.

[popbee]

What's wrong with binding expressions?

We consider new features based on user feedback.

Where to express the feedback? I'll post here.

Polymer is designed for building Web Components, it's not primarily focused on being a general purpose templating library.

...Then tell us how to use a "general purpose templating library" when writing Polymer components. I have yet to see a solution.

Do you agree that not having expressions inside HTML feels backwards nowadays?

I mean, do you deny Binding/Templating Expression's popularity? To me, it is very easy to understand and attractive. We cannot say the same for computed bindings / filters! They are hard to read (unless you are really good with your naming conventions), not easy to code (have to not only create a piece of code completely elsewhere but one has to give it a name even for simple things like "{{index%2==0}}".

Half-baked solution:
In Polymer 1.0 you left the "bang" (!) operator. I didn't read anywhere the reason why bang operator was still available. Please explain this. Guess what: I'll use your explanation in favor to full blown expressions! Frankly, what is the difference between something like "{{!shown}}" and "{{index + 1}}"?

From a high level:
One beauty of javascript is inline (&anonymous!) functions. Code is next to where it is used. Well, binding expressions is very similar! Code exactly where it's needed (and for simple things, without the hassle of naming it and maintaining an "external" piece of code).

[Tomucha]

@popbee I would like this too, please express your feedback also here:
https://plus.google.com/u/1/+TomasZverina/posts/W43sPHaFysE

[popbee]

Sure did. I will support any effort to have better "extrapolations" (or whatever they like to call it) with Polymer. Either within the core (better as everybody would align) or at least a solution supported by Polymer docs / people (or anything going in that direction).

AFAIK I have yet to see a [good] demonstration of why this would be "wrong" or would slow down anything. I am opened to hear it.

I must confess that this very feature [or lack thereof] is what "killed" Polymer for me. As of now, I did not upgrade existing projects to 1.0 and went the ReactJS [& related] route for new ones.

[larsgk]

It might be that having expressions and filters introduce a performance hit where used - but from a development standpoint, it's VERY useful to have.

Some examples:

• [[value | currency]] will know the locale and format the number (as with angular - https://docs.angularjs.org/api/ng/filter/currency)
• [value & 0xff] expressions are not allowed in 1.x and 2) HEX values - apparently - are not considered numerals (why not? - a bug?) - I had to change it to [[_bitMask(value, 255)]]
• any date/time rendering filters, custom output for dev/debugging - e.g. as "json" in angular

With the current "solution" in 1.x, you will need something like a super-master-behavior, inherited by ALL elements (including built-in) that has a ton of functions to compensate for missing filters and expressions - OR make custom functions and inheritance of built in elements all over. In any case, the templates will become filled with function calls and it will not be easy to understand the exact behavior at first glance. In the larger web projects, I've been working on (angular & some ember), I'd say filters were used in maybe 25% of the rendered bindings to make things easily localizable, custom formatted, etc. + the occational simple calculation or bit mask.