Promises inside Components...not a good idea?

1

Hi there,

Take a look at JS Bin - Collaborative JavaScript Debugging , bring up the console and navigate quickly (faster than 1s) between the first and second route.

You should see the error message

Assertion Failed: calling set on destroyed object

Furthermore, imagine the Ember.run.later... to be a promise…didn’t know how to simulate a long running promise. The effect/error is the same.

The error happens because I call set this.set('barfoo', 'somevalue'); on a component that has already been destroyed after navigating to another route.

One way to avoid this error is to wrap the set inside an if (!this.isDestroyed), but somehow it does not feel right…

So should I avoid promises inside components? I have the feeling that you should be able to use them in components… What is your view on this? Especially having in mind that Ember is moving towards a Component centric philosophy…

There already has been some debate about this on How to make ember component fetch data from server. put AJAX call inside the component seems not a good practise to handle this

2

From what I’ve read, I think its acceptable way of doing it e.g. ember asyn button add-on does the same check for the promise you pass in.

Discussion here might help/guide you Routable Components RFC by ef4 · Pull Request #38 · emberjs/rfcs · GitHub

I recently built a component that uses the ember promise mixing, its not dependant on any route (same modal window that opens in different routes) so it loads its own data and checks isDestroyed before setting any data.

Plus each component has its own loading state.