Refactor binding regex to small scanner to allow custom expressions to be defined

[TimvdLippe]

Previous related issues

At the moment all bindings are parsed using a regex. A frequent request for 1.0 is expansion of other expressions:

• Ternary operator in binding expressions (Ternary operator in binding expressions #4038)
• Feature Request: Support !! in bindings (Feature Request: Support !! in bindings #3188) and Double negation support (Double negation support #2343)
• Some default computed bindings methods (Some default computed bindings methods #2237)

There was a previous effort to extract a separate library for expression at https://github.com/Polymer/polymer-expressions/tree/2.0-preview

How not to bloat the library

The general argument for not including this expressions is: it bloats the library. I completely agree with this statement. Therefore to provide flexibility for parsing the bindings, it would be nice to find a solution that 1. does not add bloat, but 2. is customizable to the users need. With the ability to define your own base class in Polymer 2.0, custom bindings could be a lot easier.

Proposed solution

To make this work, I did some hacking but got stuck quite fast. The main issue is that the regex is at the moment very limiting and you can't easily override/extend/modify this regex on runtime. All functions in the annotations file are static and have no instance attached.

Therefore it would be nice to replace the regex with a very simple scanner that verifies that a binding exists (e.g. between {{}} or [[]]). Then it will extract everything between the bindings and pass these values on. The values are pre-processed when the constructor of the custom element is run, which invokes a static method called processBindingValue. The default implementation of Polymer.Element uses parts of the original regex to parse strings, numbers, variables and function calls.

Now the benefit of this approach is that users can override the method and supply their custom parsing. Since ES6 classes are used, super.processBindingValue can be invoked to fallback to the implementation defined in Polymer.Element. Users can then also mix in multiple behaviors with their own binding parsers to compose multiple expressions at once.

Benefits of this approach

Since ES6 classes are used, the user can really easily override the base method defined in Polymer.Element. Most of the users won't and therefore there should not be any performance degradation. Users can opt-in, but have fully control on how they want to parse the bindings.

CC @sorvell this issue was a result of our discussion at the Polymer summit last monday.

[jfrazzano]

How do you plan on building library?

I have been string tenplating and binding a month or so and have been looping patterns in get sets

The strings allow the on the fly
Quirky [janky code] binds and decision making

But in the last two days I have been experimenting with placing the event handler in a property "touchDom"

And then chaining other gets and sets on same pattern and for same usage as ternary without the "bind every time" issue

I saw the possibility late in a long sleepless code cycle, Inawake testing have not had time/define properties on my Mac has been janky with this in descriptors

To see if it will work

But in theory it should be a better approach

Gets sets plus returns of template strings then amalgammated in master prototype object

In theory

Would offer modular Dom and value binding omni directionally build the Dom and be repetitive and simple.

As we both know, however, we don't live in theory.

You're welcome to any of my work

And am willing to do grunt work that aligns in purpose

Let me know

I"lol pass some pvt Pens so you can see what I am up to
Sent from my iPhone

On Oct 20, 2016, at 5:02 PM, Tim van der Lippe [email protected] wrote:

Previous related issues

At the moment all bindings are parsed using a regex. A frequent request for 1.0 is expansion of other expressions:

Ternary operator in binding expressions (#4038)
Feature Request: Support !! in bindings (#3188) and Double negation support (#2343)
Some default computed bindings methods (#2237)
There was a previous effort to extract a separate library for expression at https://github.com/Polymer/polymer-expressions/tree/2.0-preview

How not to bloat the library

The general argument for not including this expressions is: it bloats the library. I completely agree with this statement. Therefore to provide flexibility for parsing the bindings, it would be nice to find a solution that 1. does not add bloat, but 2. is customizable to the users need. With the ability to define your own base class in Polymer 2.0, custom bindings could be a lot easier.

Proposed solution

To make this work, I did some hacking but got stuck quite fast. The main issue is that the regex is at the moment very limiting and you can't easily override/extend/modify this regex on runtime. All functions in the annotations file are static and have no instance attached.

Therefore it would be nice to replace the regex with a very simple scanner that verifies that a binding exists (e.g. between {{}} or [[]]). Then it will extract everything between the bindings and pass these values on. The values are pre-processed when the constructor of the custom element is run, which invokes a static method called processBindingValue. The default implementation of Polymer.Element uses parts of the original regex to parse strings, numbers, variables and function calls.

Now the benefit of this approach is that users can override the method and supply their custom parsing. Since ES6 classes are used, super.processBindingValue can be invoked to fallback to the implementation defined in Polymer.Element. Users can then also mix in multiple behaviors with their own binding parsers to compose multiple expressions at once.

Benefits of this approach

Since ES6 classes are used, the user can really easily override the base method defined in Polymer.Element. Most of the users won't and therefore there should not be any performance degradation. Users can opt-in, but have fully control on how they want to parse the bindings.

CC @sorvell this issue was a result of our discussion at the Polymer summit last monday.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[dfreedm]

This is something that could be handled by #3369