Polymer: Support data binding to promises

[MaKleSoft]

This would be a killer feature imo, especially if used with computed bindings. Here is an example:

<div>[[ _myAsyncValue(prop1, prop2) ]]</div>

_myAsyncValue(prop1, prop2) {
  return new Promise((resolve, reject) => {
    // Something asynchronous, like doing an ajax call, spawning a web worker, etc.
  });
}

Thoughts?

[rictic]

At the goals-level (before talking about implementation), I generally want to know and databind to three values per promise:

• a Boolean that's true while the promise is unfulfilled
• the resolution
• the rejection

(And I want resolution and rejection to be mutually exclusive, so at most one is non-null).

[dfreedm]

Since you can already do something like this by binding to a property that is resolved by a promise, I don't think there is enough need to put this directly into the data binding system.

Example:
```js
static get properties() {
return {
asyncProperty: {
type: Object
}
}
//...
someFn() {
new Promise((resolve, reject) => {
//...
}).then((result) => this.asyncProperty = result)
}

[MaKleSoft]

Excuse me, but how is "it can already be done in a more roundabout way using significantly more boilerplate" a reason to not even consider this? By the same logic, you could say "Hey, we don't need promises at all, everything can be done with callbacks!" or "Arrow functions? Whats wrong with .bind(this)?" Hell, couldn't the same even be said for computed bindings? (Can be achieved using observers).

With native Promises in ES2015 and async/await coming in ES2017, Promise are quickly becoming a first-class citizen in the JavaScript world and I think it would be an oversight to not treat them as such.

Now, can we please reopen this to continue the discussion instead of just dismissing it like this? I mentioned boilerplate as the most obvious argument but I see many more advantages to supporting Promises out of the box. Also, I'd like to hear a better argument against it than "it's not strictly needed".

[dcbrwn]

Feature like this once was available in Angular 1.x but then was dismissed:
https://github.com/angular/angular.js/commit/5dc35b527b3c99f6544b8cb52e93c6510d3ac577

Even though I understand the desire to keep Polymer core as simple as possible, IMO @MaKleSoft is right. With promises literally everywhere it gets very annoying to do this over and over again.

[jasonwr]

I concur with @dcbrwn and @MaKleSoft on this one. It would be fantastic indeed.

[dcbrwn]

@MaKleSoft @jasonwr looks like polymer 3 will use lit-html for templates, and it supports promises: https://youtu.be/ruql541T7gc?t=13m4s

[jasonwr]

@dcbrwn yeah that sounds awesome. I'll try this out tonight and let you know what I find and how it integrates because I do have a Polymer 3 component but the HTML template loading is cumbersome (string based). lit-html should help us avoid using webpack etc. For everyone's reference here's the link to lit-html from PolymerLabs: https://github.com/PolymerLabs/lit-html