Ember's computed properties should properly unwrap nested promises

[foxnewsnetwork]

If you have an object which has a field that is a promise to another object, ember's computed property that depends on that promise should properly update once that promise has been resolved.

For example, say you're build some sort of forum software, and you have a Thread model which has a topicPost field which is a promise to a Post model. The Post model has a field called "owner" which is a string. If on your thread model, you have:

Thread = Ember.Object.extend
  op: Ember.computed.alias "topicPost.owner"

You would expect that once thread.get("topicPost") resolves, thread.get("op") should resolve to the owner string on the topicPost object... but it doesn't and instead ember's get is confounded at dealing with the promise.

Here's the codepen illustrating this:

http://codepen.io/foxnewsnetwork/pen/wBZKzx?editors=101

[igorsantos07]

I encountered that issue as well. That seems pretty important as it seems quite different from what end users will expect from the framework...
I found a pretty bad (but working) workaround for that: http://stackoverflow.com/questions/20623027/rendering-resolved-promise-value-in-ember-handlebars-template

[igorsantos07]

I encountered that issue as well. That seems pretty important as it seems quite different from what end users will expect from the framework...
I found a pretty bad (but working) workaround for that: http://stackoverflow.com/questions/20623027/rendering-resolved-promise-value-in-ember-handlebars-template

[jvenator]

+1 on this. I have a scenario where there is a contentItem resource with an async hasMany relationship to a Tag resource. In one of views/routes I want to display a composed string of the tags for a given contentItem, and have attempted to create a property in the contentItem model using Ember.computed. No matter how I structure it or set return values, it results in a promise. This thread in the ember discussion forum shows that even some of the heavy hitters struggle with this, and require a hack like this one to get around it.

[jvenator]

+1 on this. I have a scenario where there is a contentItem resource with an async hasMany relationship to a Tag resource. In one of views/routes I want to display a composed string of the tags for a given contentItem, and have attempted to create a property in the contentItem model using Ember.computed. No matter how I structure it or set return values, it results in a promise. This thread in the ember discussion forum shows that even some of the heavy hitters struggle with this, and require a hack like this one to get around it.

[stefanpenner]

We have plans to making promises work natively in our streams and bindings systems, that doesn't fix all annoyances but moves stuff along in the correct direction.

This isn't a bug, rather a feature that does not exist. If someone wants to push this forward, feel free to open an issue on the RFC repo, or if they are so inclined a a full RFC.

[stefanpenner]

We have plans to making promises work natively in our streams and bindings systems, that doesn't fix all annoyances but moves stuff along in the correct direction.

This isn't a bug, rather a feature that does not exist. If someone wants to push this forward, feel free to open an issue on the RFC repo, or if they are so inclined a a full RFC.

[jvenator]

Thanks for the update @stefanpenner

[jvenator]

Thanks for the update @stefanpenner