I am concerned about references I have seen to Parse using JQuery-compatible promises, as I have read that jQuery promises allow consumers to mutate the state of the promise. Is it possible to use another promise implementation that is known to be Promises/A+ compliant (e.g. the ECMAScript 6 implementation, or Bluebird) with the Parse JavaScript SDK?
Normally I would assume that this isn’t possible, but in v1.4.2 of the Parse JavaScript SDK, the implementation of Parse.Promise defines the property “_isPromisesAPlusCompliant” as false which is then checked in various functions within the library.
N.B. This question was originally asked on the Parse Developers group, but received no responses.
You don't need to be concerned. "jQuery-compatible" can mean a lot of things, and Parse promises do certainly not allow consumers to mutate their state1 (as jQuery doesn't do either since years now). Btw, they're A+ "compatible" as well :-)
1: through the public methods. So not more than most other implementations, that is.
Yes. The Parse SDK does return valid A+ thenables, which means that you can return Parse promises from
then
callbacks of your favourite promise implementation and expect it to work flawlessly:You can also cast them into valid promises of your implementation by using
Promise.resolve
, for example:He! Although it is unfortunately undocumented, this flag does actually allow you to make the native Parse.com promise library A+ compliant in your app:
Update: In newer versions, this is not exposed as an underscored property, but rather you have to call the (undocumented)
Parse.Promise.enableAPlusCompliant()
method. For details see issue #57.I've reviewed the code, and this flag basically changes 3 things:
then
callbacks are caught and lead to the rejection of the result promise, instead of a global error. So you can usethrow
in them.return
a value from theonRejected
callback (second parameter tothen
), the error is supposed to be handled and the result promise is fulfilled instead of being rejected.then
callbacks are executed asynchronously.These are indeed solving exactly the problems inherent to the jQuery
Deferred
implementation at the current time.I'll assume that Parse are planning to silently migrate this
true
setting to become the default, and are testing whether it breaks anything for the users. I'd guess that it is pretty safe to use even if undocumented yet.That's not so simple, although it can be done. There are basically two approaches:
Promise.resolve
, which is basically what @dancamper suggestedParse.Promise
with a wrapper around your library.The second seems to be more efficient and stable, it's more maintainable as it doesn't require tweaking when Parse change their API.
2:
Promise.all
resolves to an array, whileParse.Promise.when
resolves with multiple arguments (see below). You may want / need to preserve this and usepromise.when = oldPromise.when;
instead.3: Make sure not to overwrite methods of your custom library here. Parse doesn't need these methods, they're for jQuery compatibility.
Notice that Parse does, like jQuery, sometimes resolve its promises with multiple values, e.g. in
Parse._ajax
. It doesn't rely on this feature internally, but you should check how your favourite promise library copes with them.