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
thencallbacks 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:
thencallbacks are caught and lead to the rejection of the result promise, instead of a global error. So you can usethrowin them.returna value from theonRejectedcallback (second parameter tothen), the error is supposed to be handled and the result promise is fulfilled instead of being rejected.thencallbacks are executed asynchronously.These are indeed solving exactly the problems inherent to the jQuery
Deferredimplementation at the current time.I'll assume that Parse are planning to silently migrate this
truesetting 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.Promisewith 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.allresolves to an array, whileParse.Promise.whenresolves 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.