Is it required to wrap non-Ember Promises (or Rx.Observables, or any async operations) in Ember Promises

1

I’m working on an app that relies heavily on a non-Ember library, Falcor to handle API calls. Is it required that all Falcor calls be wrapped in Ember Promises? E.g. if I’m doing something like

falcor.get(falcorPath)
  .subscribe(onNext, onError, onComplete);

do I always need to wrap this in an Ember promise, like so:

new Ember.RSVP.Promise((resolve, reject) =>
  falcor.get(falcorPath)
    .subscribe(res => {
      // handle onNext
    }, err => {
      // handle error
      resolve();
    }, () => {
      // handle finally callback
      reject();
    });

If the Ember Promise is required (seem to remember it makes tests aware of async behavior…?), then wondering if there might be any patterns to make Ember aware of Rx.Observables w/o the wrapping boilerplate.

Thanks for the help.

2

Never used Falcor, but that looks like an Observable. You don’t have to convert it to Promise. You just need to subscribe then call .set on some object.

But I think a better solution is have some way to convert an Observable into a Computed Property. Maybe someone else knows of an addon that does this?

3

I guess what I’m wondering is more general: does Ember require that all async operations (whether an Observable, non-Ember Promise, or even just a generic ajax call) be wrapped in an Ember.RSVP.Promise, so that Ember can be aware of the async behavior (either for the sake of the run cycle, testing, or some such). Or can I safely remove the Ember Promise? I seem to remember that the RSVP.Promise is required, but can’t find any documentation on why (or if there’s a better pattern with which to register Observers ).

4

I guess what I’m wondering is more general: does Ember require that all async operations (whether an Observable, non-Ember Promise, or even just a generic ajax call) be wrapped in an Ember.RSVP.Promise,

Observable, no. non-Ember Promise, yes $.ajax, yes

5

Observable, no. non-Ember Promise, yes $.ajax, yes

Thanks for the response.

What’s the rationale here? Given that an Observable can (and often does) wrap async operations like an ajax call, why would it be safe not wrapped in an Ember Promise, while the others wouldn’t?

More specifically, what is lost by not wrapping? (As for what is gained by not wrapping, some reduction of boilerplate, and more importantly the ability to pass Observables, rather than only Promises)