# Promises and computed properties

**URL:** <https://discuss.emberjs.com/t/promises-and-computed-properties/3333>\
**Category:** Uncategorized\
**Created:** [November 13, 2013, 8:01am UTC](https://discuss.emberjs.com/t/promises-and-computed-properties/3333 "2013-11-13T08:01:03Z")\
**Posts on this page:** 19\
**Page:** 2

<div class="post-metadata">

**Author:** ![ultimatemonty](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/ultimatemonty/32/13849_2.png) [@ultimatemonty](https://discuss.emberjs.com/u/ultimatemonty)\
**Post date:** [November 13, 2014, 10:22pm UTC](https://discuss.emberjs.com/t/promises-and-computed-properties/3333/21 "2014-11-13T22:22:10Z")

</div>

I have a very similar situation where I have a route that displays a filtered array based on a query param.

```javascript
App.Location = DS.Model.extend({
   ...
   sites: DS.hasMany('site', { async: true })
   ...
});

App.Site = DS.Model.extend({
   ...
   siteCategory: DS.belongsTo('site-category', { async: true })
   ...
});

App.SiteCategory = DS.Model.extend({
   ...
   name: DS.attr('string')
   ...
});

```

My route returns back all related `sites` for a location then each tab sets the query param to a different `siteCategory` name to filter the data. This works fine when clicking from one tab to another but not on the initial load due to unresolved promises:

```auto
queryParams: ['siteCategory'],
siteCategory: null,

sortProperties: ['isActive', 'name'],
sortedContent: Ember.computed.sort('model', 'sortProperties'),
filteredContent: Ember.computed('siteCategory', 'model.@each.isDeletedFromApplication', function () {
    var self = this;
    var sites = this.get('sortedContent');
    var siteCategory = this.get('siteCategory');

    return sites.filter(function (site) {
        // logs UNDEFINED on page load
        // logs the proper value when the queryParam changes
        console.log(site.get('siteCategory'),get('name');
        return site.get('siteCategory').get('name') === siteCategory && 
               !site.get('isDeletedFromApplication');
    });
})

```

Would love to know how to work around the unresolved promises in `filteredContent` on first load.

---

<div class="post-metadata">

**Author:** ![manmal](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/manmal/32/3794_2.png) [@manmal](https://discuss.emberjs.com/u/manmal)\
**Post date:** [November 14, 2014, 7:21am UTC](https://discuss.emberjs.com/t/promises-and-computed-properties/3333/22 "2014-11-14T07:21:56Z")

</div>

The approach described by ef2 above should work here. I used it like so: [https://gist.github.com/manmal/4a9836922e11157d7ecf](https://gist.github.com/manmal/4a9836922e11157d7ecf) (actual working example).

I haven’t written Ember code for a while now, but what I think could work in your example is to create a big, fat promise for all that stuff that you currently have inside the `function() {...}`, and then use it like so (using promisedProperty.coffee from my gist):

```
filteredContent: promisedProperty(someDefaultValue, -> 
  # insertYourBigFatPromiseDefHere
).property('sortedContent', 'siteCategory')

```

---

<div class="post-metadata">

**Author:** ![jayphelps](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/jayphelps/32/9358_2.png) [@jayphelps](https://discuss.emberjs.com/u/jayphelps)\
**Post date:** [November 20, 2014, 1:38am UTC](https://discuss.emberjs.com/t/promises-and-computed-properties/3333/23 "2014-11-20T01:38:23Z")

</div>

I’ve been toying with this issue lately as well…Particularly the case where I want to show feedback of the promise’s state (loading/error). I hacked together [this `{{render-with-promise}}` helper](http://emberjs.jsbin.com/galige/1/edit) as a proof of concept of what IMO is gold. Basically just removes the state checking boilerplate and gives you `loading`/`error` psuedo-substates for free in the same fashion as route-backed promises do, but unlike routes you can render multiple promise-based resources on the same page at once since you don’t need to maintain URL state.

Most often, this is handy for dashboard/widget style views where you are loading many different calls individually and don’t want to halt the page transition (as `RSVP.hash()` would).

Feedback welcome.

---

<div class="post-metadata">

**Author:** ![ThomasDurin](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/thomasdurin/32/9859_2.png) [@ThomasDurin](https://discuss.emberjs.com/u/ThomasDurin)\
**Post date:** [November 20, 2014, 9:46am UTC](https://discuss.emberjs.com/t/promises-and-computed-properties/3333/24 "2014-11-20T09:46:54Z")

</div>

Are these issues between promises and computed properties are gonna be fixed? (next release of Ember data) I would like to use Ember data in one of my projects but I’m concern about this… It’s actually pretty hard to find a work around. There’s few month I read that the DataBoundPromise were supposed to be used inside computed properties. What about it ?

Would love to know if someone has some work around or feedback.

---

<div class="post-metadata">

**Author:** ![brancusi](https://avatars.discourse-cdn.com/v4/letter/b/5f9b8f/32.png) [@brancusi](https://discuss.emberjs.com/u/brancusi)\
**Post date:** [December 26, 2014, 12:06am UTC](https://discuss.emberjs.com/t/promises-and-computed-properties/3333/25 "2014-12-26T00:06:11Z")

</div>

Would love to see some examples for this as well. I have a firebase backed project full of async relationships.

---

<div class="post-metadata">

**Author:** ![shaunc](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/shaunc/32/5422_2.png) [@shaunc](https://discuss.emberjs.com/u/shaunc)\
**Post date:** [January 9, 2015, 2:10am UTC](https://discuss.emberjs.com/t/promises-and-computed-properties/3333/26 "2015-01-09T02:10:53Z")

</div>

What I have been doing is adding a `_resolve` property to my models, which build new properties based on relevant promise-returning properties. (Convention – for a promise property `_foo` I have a property `foo` which is undefined when promise unresolved and then set to the resolution when it resolves.)

I get `_resolve` in root `afterModel` … this works, but involves some unfortunate coupling & boilerplate. One problem is that I need to call `_resolve` on all the models used – so root needs to know what is used (See [Mapping queryParams -- proposal or request for best practice](http://discuss.emberjs.com/t/mapping-queryparams-proposal-or-request-for-best-practice/7050)).

Currently, using the router seems to be the “best practice” for resolving promises… but the mapping from routes to application state isn’t perfect.

---

<div class="post-metadata">

**Author:** ![nandosan](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/nandosan/32/267_2.png) [@nandosan](https://discuss.emberjs.com/u/nandosan)\
**Post date:** [January 9, 2015, 12:53pm UTC](https://discuss.emberjs.com/t/promises-and-computed-properties/3333/27 "2015-01-09T12:53:33Z")

</div>

Isn’t this a replication of the `PromiseObjectMixin` ?

---

<div class="post-metadata">

**Author:** ![shaunc](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/shaunc/32/5422_2.png) [@shaunc](https://discuss.emberjs.com/u/shaunc)\
**Post date:** [January 9, 2015, 2:40pm UTC](https://discuss.emberjs.com/t/promises-and-computed-properties/3333/28 "2015-01-09T14:40:25Z")

</div>

I could have been using `PromiseObjectMixin` (wasn’t aware of it). Either way the coupling problem remains as routes can’t be specified in enough precision to capture application state, and they need to know what to resolve whatever the method.

---

<div class="post-metadata">

**Author:** ![andrew1](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/andrew1/32/10636_2.png) [@andrew1](https://discuss.emberjs.com/u/andrew1)\
**Post date:** [April 7, 2015, 5:35pm UTC](https://discuss.emberjs.com/t/promises-and-computed-properties/3333/29 "2015-04-07T17:35:50Z")

</div>

This does the right thing and I think will help me work around some hacky code in our app but Ember is complaining that I can’t call set because this has already been destroyed:

```
Assertion failed: calling set on destroyed object

```

The promise is a Q promise not Ember.RSVP.Promise if that makes a difference. Any ideas how to work around this?

Thanks!

---

<div class="post-metadata">

**Author:** ![ef4](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/ef4/32/13470_2.png) [@ef4](https://discuss.emberjs.com/u/ef4)\
**Post date:** [April 7, 2015, 7:05pm UTC](https://discuss.emberjs.com/t/promises-and-computed-properties/3333/30 "2015-04-07T19:05:28Z")

</div>

That error means that your object got destroyed while the promise was still resolving. You can defend against that by checking `this.isDestroyed` before calling `set`.

---

<div class="post-metadata">

**Author:** ![jvenator](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/jvenator/32/4035_2.png) [@jvenator](https://discuss.emberjs.com/u/jvenator)\
**Post date:** [July 7, 2015, 7:02pm UTC](https://discuss.emberjs.com/t/promises-and-computed-properties/3333/31 "2015-07-07T19:02:40Z")

</div>

Has there been any movement on this, or is the workaround from @ef4 still the way to address it? FWIW the workaround was effective for me.

The scenario I have is creating `tagString` property on a `post` resource/model that represents a composed string of the tags associated with a given post. No matter how structure/sequence things making use of `return` or `.then()` I end up with a promise as the result. Seems like a reasonable scenario that deserves some mechanism within the framework to deal with.

My modestly informed 2 cents…

---

<div class="post-metadata">

**Author:** ![jthoburn](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/jthoburn/32/12401_2.png) [@jthoburn](https://discuss.emberjs.com/u/jthoburn)\
**Post date:** [July 8, 2015, 9:34pm UTC](https://discuss.emberjs.com/t/promises-and-computed-properties/3333/32 "2015-07-08T21:34:26Z")

</div>

The way I solve this currently is for components that have a LOT of run loop calls or promises I add them to a little async manager which ensure that on `willDestroy` they are all torn down or cancelled appropriately.

---

<div class="post-metadata">

**Author:** ![andrew1](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/andrew1/32/10636_2.png) [@andrew1](https://discuss.emberjs.com/u/andrew1)\
**Post date:** [July 11, 2015, 7:34pm UTC](https://discuss.emberjs.com/t/promises-and-computed-properties/3333/33 "2015-07-11T19:34:13Z")

</div>

@ef4’s suggestion is actually the solution to the problem and not a “work-around.” This is something I managed to overlook for a solid year of coding in Ember but you need to clean up anything that can happen later in `willDestroy()`. This includes promises as well as anything that you’ve put off with a `debounce` or `runLater` call. This has solved a lot of weirdness in our specs where we had to wrap a lot of code in `Ember.run`. It’s also solved most of weird, intermittent spec failures we were having.

---

<div class="post-metadata">

**Author:** ![ef4](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/ef4/32/13470_2.png) [@ef4](https://discuss.emberjs.com/u/ef4)\
**Post date:** [July 12, 2015, 2:08pm UTC](https://discuss.emberjs.com/t/promises-and-computed-properties/3333/34 "2015-07-12T14:08:08Z")

</div>

Yeah, you can’t avoid dealing with asynchrony.

However, I do think there are still opportunities to make the framework handle more cases more declaratively.

---

<div class="post-metadata">

**Author:** ![Bob\_Myers](https://avatars.discourse-cdn.com/v4/letter/b/bc79bd/32.png) [@Bob\_Myers](https://discuss.emberjs.com/u/Bob_Myers)\
**Post date:** [July 12, 2015, 7:56pm UTC](https://discuss.emberjs.com/t/promises-and-computed-properties/3333/35 "2015-07-12T19:56:20Z")

</div>

Take a look at [GitHub - bengillies/ember-parallel: An Ember.js plugin proving integration with Parallel.js](https://github.com/bengillies/ember-parallel).

---

<div class="post-metadata">

**Author:** ![ecguo](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/ecguo/32/15871_2.png) [@ecguo](https://discuss.emberjs.com/u/ecguo)\
**Post date:** [August 8, 2015, 7:56am UTC](https://discuss.emberjs.com/t/promises-and-computed-properties/3333/36 "2015-08-08T07:56:43Z")

</div>

> [@aexmachina](#):
>
> {{#if facebookPicture.isFulfilled}} {{facebookPicture.content}} {{/if}}

It’s the correct answer, using computed properties to handle promises and waiting to resolved before display in template is wrong, because template render shouldn’t blocked by a promise.(if still in pending), instead once the promised fulfilled, the template should be refresh.

That’s the Ember Way™

---

<div class="post-metadata">

**Author:** ![devotox](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/devotox/32/12339_2.png) [@devotox](https://discuss.emberjs.com/u/devotox)\
**Post date:** [August 16, 2016, 1:10am UTC](https://discuss.emberjs.com/t/promises-and-computed-properties/3333/37 "2016-08-16T01:10:03Z")

</div>

> [@shaunc](#):
>
> [Mapping queryParams -- proposal or request for best practice](http://discuss.emberjs.com/t/mapping-queryparams-proposal-or-request-for-best-practice/7050)

This was perfect i created a service and just works out of the box

import Ember from ‘ember’;

export default Ember.Service.extend({ promiseProxy(promise) { let ObjectPromiseProxy = Ember.ObjectProxy.extend(Ember.PromiseProxyMixin); return ObjectPromiseProxy.create({ promise: promise }); }, });

---

<div class="post-metadata">

**Author:** ![lightblade](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/lightblade/32/15632_2.png) [@lightblade](https://discuss.emberjs.com/u/lightblade)\
**Post date:** [August 16, 2016, 4:04am UTC](https://discuss.emberjs.com/t/promises-and-computed-properties/3333/38 "2016-08-16T04:04:10Z")

</div>

Ember Data has some utilities for this purpose: `DS.PromiseObject` and `DS.PromiseArray`. These are `ObjectProxy` mixed with `PromiseProxyMixin`

---

<div class="post-metadata">

**Author:** ![emberigniter](https://avatars.discourse-cdn.com/v4/letter/e/aca169/32.png) [@emberigniter](https://discuss.emberjs.com/u/emberigniter)\
**Post date:** [October 30, 2016, 5:39am UTC](https://discuss.emberjs.com/t/promises-and-computed-properties/3333/39 "2016-10-30T05:39:58Z")

</div>

While refreshing content when a promise is resolved is a useful pattern, Ember routing relies on _waiting_ for promises to resolve before rendering – I don’t think there is one single “Ember way” here.

In many cases, for example when navigating the object graph (say `post.comments`) in our components, we are forced to deal with async outside of the route hooks.

There was a lot of discussion around this. For those interested, here is an article I wrote not long ago with best practices for dealing with promises in computed properties: [The Guide to Promises in Computed Properties - Ember Igniter](https://emberigniter.com/guide-promises-computed-properties/)

[Previous page](https://discuss.emberjs.com/t/promises-and-computed-properties/3333.md?page=1)