Skip to content
This repository has been archived by the owner on May 29, 2019. It is now read-only.

WIP: Add strict binding parser note #2665

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 38 additions & 0 deletions app/2.0/docs/devguide/data-binding.md
Original file line number Diff line number Diff line change
Expand Up @@ -697,6 +697,44 @@ to listen for `property-changed` events. The following constructions are equiva
<my-element value="{{hostValue}}">
```

## Strict binding parser

The default implementation of the binding parser uses a regular expression, due to its better
Copy link

@arthurevans arthurevans Oct 26, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this! I'd like to suggest alternate text to focus more on the use cases (when you need it, what to do) and less on the implementation. Here's my first take:

The default binding parser emphasizes performance over completeness. Some bindings can't be parsed correctly by the default parser—for example, bindings with JavaScript identifiers that include non-ASCII characters.

For a more exact binding parser, use the StrictBindingParser mixin. This mixin provides an alternate binding parser that handles all possible cases, although it's slightly less performant than the default parser.

I don't love the phrase, "handles all possible cases," but I can't think of anything better at the moment, either.

Copy link
Author

@twin-tigon twin-tigon Nov 7, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the feedback. Regarding the last sentence, what about something like this:

This mixin provides an alternate binding parser that supports Unicode characters, although it's slightly less performant than the default parser.

performance. However, since it uses a white-list of allowed characters, some characters won't be
accepted as valid within a binding expression.

There's a strict binding parser implementation, extracted in a separate mixin, which uses a
state-machine instead of a regular expression. This implementation is able to handle all possible
cases, although it's slightly less performant.

Example: { .caption }

```
<link rel="import" href="../polymer/polymer-element.html">
<link rel="import" href="../polymer/lib/mixins/strict-binding-parser.html">

<dom-module id="polymer-strict-binding-parser-example">
<template>
<span>[[título]]</span>
</template>

<script>
class PolymerStrictBindingParserExample extends Polymer.StrictBindingParser(Polymer.Element) {
static get is() { return 'polymer-strict-binding-parser-example'; }
static get properties() {
return {
título: {
type: String,
value: 'Mi título'
}
};
}
}

window.customElements.define(PolymerStrictBindingParserExample.is, PolymerStrictBindingParserExample);
</script>
</dom-module>
```

## Moved sections

Expand Down