Configuration points for Promise

[benlesh]

We need to add a configuration point for using alternative Promise libraries. We also need to allow developers to pass a Promise constructor to each method that might create a Promise internally. forEach once such example.

• add configuration point for Promises
• add optional Promise constructor parameter to forEach

[benlesh]

Relates to #114

[jeffbcross]

We could use dependency injection :)

[benlesh]

@jeffbcross perhaps we could enable dependency injection... But I'm happy to read your suggestion

[jeffbcross]

I'm not really advocating for DI here, this is just a problem that DI solves easily (overriding bindings).

[jeffbcross]

@Blesh do you have real-world use cases to drive this design? There are a couple of cases that come to my mind:

• toPromise fails because there's no global Promise as expected. <- could be easily fixed by using a polyfill that adds Promise to global/window: https://github.com/jakearchibald/es6-promise#auto-polyfill
• User wants the promise returned from toPromise to be a promise they like, like bluebird. <- Doesn't bluebird provide a way of casting an A+ promise to a bluebird promise?

Are there other cases I'm missing, or are there reasons why my suggestions don't satisfy those use cases?

[mattpodwysocki]

@jeffbcross yes, we do because of what already exists in RxJS. Not only that, but if someone wants to use something other than the standard promise, eg Bluebird, we can specify the object there. PouchDB and others do this as well.

[jeffbcross]

Thanks @mattpodwysocki, I'm looking for real-world use cases to help me understand the issue. What makes the existing options painful for users? What are the most common reasons for using toPromise in the first place? Interoperability with other libs? Familiarity?

[benlesh]

@jeffbcross

There are a few use cases for using toPromise:

1. await myObservable.toPromise() ... although I think @zenparsing wants to change the last() operator to just be a method that returns a promise in the ES7 Observable, rather than an operation.
2. someFunctionThatExpectsAPromise(myObservable.toPromise())
3. Things that expect you to return a promise, like Ember's Route.prototype.model or Angular's routing resolve configuration, where it expects you to return a promise.

[jeffbcross]

@Blesh those are use cases for toPromise, which I already intuitively understand. I'm just missing context on why it's painful for users to polyfill or manually cast the promise returned by toPromise to a different compliant promise of their choice. I.e. what's an example of a type of application that would have toPromise in a hot, high-frequency code path, where the overhead of re-casting would have significant penalty. Or an application that has 100 instances of toPromise in the code base where the boilerplate of all the lines of code required to re-cast the promise to something else is out of control. To clarify, I'm not challenging the validity of the issue, just trying to understand since I have a lot less background on RxJS than other contributors (but I've spent a lot of time dealing with similar problems in angular).

[benlesh]

I think it's more an issue of a preferred Promise library to use. Bluebird over native for performance reasons, for example.

[benlesh]

Digging into this, the only prudent course for now is a first step, which is global configuration.

After that, we can move to an optional functional/factory style configuration, because I think we can support both. But to get this feature in in a minimal way, I'm going to opt for just global configuration so we can get Alpha out the door.