Does anyone use two-way filters in Polymer Expressions?

[Justin Fagnani]

We're looking at some changes to Polymer Expressions, possibly including removing filters in favor of function calls.

This means that expressions like {{ myList | enumerate }} would become {{ enumerate(myList) }}.

It would also mean that there's no direct replacement for two-way binding capable filters (those that return Transformers). Instead for cases where you need to format a value in an input, the element should take a formatter function or transformer itself.

We have a guess that there aren't many people using two-way filters, but we want to check before possibly making breaking changes.

So, what say you?

Thanks!

  -Justin

[tomasz.kubacki]

Hi,

I'm using two-way bound formaters, mostly for number fields - but I think I could prepare myself for change doing <my-number-editor> element and then after change update only this single implementation.

Looking forward for the decision.

Cheers,

t.k

[Justin Fagnani]

On Wed, May 21, 2014 at 10:17 PM, tomasz.kubacki <tomasz....@gmail.com> wrote:

Hi,

I'm using two-way bound formaters, mostly for number fields - but I think I could prepare myself for change doing <my-number-editor> element and then after change update only this single implementation.

Yes, that's one option. Another is <core-input formatter="{{ number }}">, and yet another _might_ be <input formatter="{{ number }}"> with a behavior (from behavior.dart) that applies the formatting. I'm not sure if that's actually possible yet.

 

Looking forward for the decision.

Me too :) We're trying to maintain pretty close compatibility with polymer.js expressions, and they are trying to simplify their implementation where they can. We'd also like them to support function/method calls, which we already do, so this might be a decent tradeoff.

We'll keep you posted.

Cheers,

  Justin

Cheers,

t.k

On Thursday, May 22, 2014 1:56:18 AM UTC+2, justinfagnani wrote:

We're looking at some changes to Polymer Expressions, possibly including removing filters in favor of function calls.

This means that expressions like {{ myList | enumerate }} would become {{ enumerate(myList) }}.

It would also mean that there's no direct replacement for two-way binding capable filters (those that return Transformers). Instead for cases where you need to format a value in an input, the element should take a formatter function or transformer itself.

We have a guess that there aren't many people using two-way filters, but we want to check before possibly making breaking changes.

So, what say you?

Thanks!

  -Justin

--
You received this message because you are subscribed to the Google Groups "Dart Web Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web+uns...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/web/.
To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/e75dbbf0-ac77-4339-a92c-8cb74c7b0fc5%40dartlang.org.

[tomasz.kubacki]

On Thursday, May 22, 2014 6:19:15 PM UTC+2, justinfagnani wrote:

[...]

Me too :) We're trying to maintain pretty close compatibility with polymer.js expressions, and they are trying to simplify their implementation where they can. We'd also like them to support function/method calls, which we already do, so this might be a decent tradeoff.

We'll keep you posted.

Thanks!

From my perspective Polymer expressions is currently the most important issue of Polymer Dart. It's around 50% of my UI dev time to fight expression quirks/bugs.

Once API stabilizes it needs really solid test coverage IMHO. Hope you will give it enough love :)

Cheers,

t.k

[george.moschovitis]

This means that expressions like {{ myList | enumerate }} would become {{ enumerate(myList) }}.

+1 

never liked the xxx | yyy syntax.

-g.

[Justin Fagnani]

Can you elaborate here? Is it problems with the expression engine, or the build process / code generator?

 

Cheers,

t.k

--
You received this message because you are subscribed to the Google Groups "Dart Web Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web+uns...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/web/.

To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/9e9d6718-3705-40ee-b5f7-d65b68f50f42%40dartlang.org.

[tomasz.kubacki]

From my perspective Polymer expressions is currently the most important issue of Polymer Dart. It's around 50% of my UI dev time to fight expression quirks/bugs.

Once API stabilizes it needs really solid test coverage IMHO. Hope you will give it enough love :)

Can you elaborate here? Is it problems with the expression engine, or the build process / code generator?

The only problem is it's still relatively immature compared to eg. Angular.dart.

Bugs like https://code.google.com/p/dart/issues/detail?id=18792 keeps me with 0.10.0-pre.1 which has it's own bug with text input binding.

It's not always clear for me whether property will be refreshed on UI or not - docs are a bit outdated and so are binding samples provided some time ago by Seth.

So every non trivial biding has to be prepared (like two way binding to select) and checked if it works in Dartium and dart2js. 

Now week ago we've had Dartium 34/35...

Don't get me wrong - it's not a rant. I really like Polymer, I know it's pre-alpha, api may change and I'm paying early adopter price. 

I do appreciate all your hard work to make it better.

Just recently it really keeps me busy :)

Cheers,

t.k