Proposal: The future of Parse.Promise

[andrewimm]

This is a public discussion around the future of Parse.Promise. As Promises are made more widely available in browsers and Node, we need to consider evolving the currently implementation to meet developer expectations and avoid fragmentation.

This document is simply a proposal, and is by no means a guarantee. We want to get developer feedback as we move the SDK forward, and we hope these discussion issues are a viable way to collect opinions on our proposals.

Parse.Promise today

Parse.Promise was originally built off of the jQuery Deferred model years ago, which means it's almost – but not quite – Promises/A+ compliant. There are a few differences, but the only one that really affects developers involves the handling of exceptions: A+ will catch an exception, while the Deferred model will propagate it upwards.

It turns out that Parse.Promise contains code to adapt to A+ semantics. Internally, we have a flag called isAPlusCompliant which is disabled by default (to maintain consistency with older versions). It's currently scoped within the module and inaccessible from userspace, but we could expose it through static methods or a CoreManager value. If we wish to move Parse.Promise forward, this would be the first step.

While this would bring Parse Promises in line with the Promises/A+ spec, they would not match the behavior of Promises found in JS. This is because the A+ spec only covers how Promises behave when resolved; it does not dictate how Promises are constructed, resolved, or rejected.
A Parse Promise can be constructed with no parameters, and can be resolved or rejected by any code, as the resolution is performed by instance methods:

let myPromise = new Parse.Promise();
// do something...
myPromise.resolve();

Native JS Promises are constructed with a callback method. It is only within this method that the resolve / reject variables are available:

let myPromise = new Promise((resolve, reject) => {
  // do something...
  resolve();
});

As such, code written for one format may be difficult to rewrite into the other format. We would like to add functionality to Parse.Promise, allowing it to be constructed using the native Promise API. Supporting both styles will maintain functionality with older codebases, but allow new developers to use Parse.Promise in a way that matches the native implementation.

Eventually, we would rewrite the internals of the SDK to match this new format. We would also modify Parse.Promise to be backed by native Promises where supported, and continue to use our polyfill when it is not available.

Proposed Timeline:

• Before 1.7, expose the isAPlusCompliant flag externally, either through methods or a CoreManager value.
• In 1.7.0, default to having isAPlusCompliant set to true. This behavior can be disabled for legacy purposes, but it will be the default for all future versions.
• Additionally in 1.7.0, allow Parse.Promise to be constructed in the same way as native Promises (new Promise(callback))
• In 1.8.0, let Parse.Promise be backed by native promises where supported; continue to polyfill methods in environments that don't include a native Promise implementation
• In 1.8.0, rewrite the internals of the SDK to use the new Promise(callback) interface.

[lacker]

I think the A+ error behavior is just better. So I support this migration

[TylerBrock]

Agreed. It was surprising to discover that the Parse JS SDK provides a promise implementation that does not behave the same way as virtually all other promise implementations for Javascript. Perhaps mentioning that the current version is not A+ compliant in the JS Guide someplace would be helpful.

[weiway]

@TylerBrock Agreed!

[RaitoBezarius]

Is the isAPlusCompliant flag exposed on the latest version of Parse JS SDK?
I am surprised to see only those keys:
["when","is","isPromisesAPlusCompliant","error","arguments","_continueWhile","as","name","caller","prototype","length"]
Whereas, the 1.6.9 seems to include the method to change them, any update on this?

I could give some help on that, because I am using async/await in my code, and it is really a pain to use wrap Parse.Promise each time.

[andrewimm]

@RaitoBezarius I'm not sure I understand the question. The value of the flag can be retrieved by calling Parse.Promise.isPromisesAPlusCompliant(), and the flag can be modified by Parse.Promise.enableAPlusCompliant() / Parse.Promise.enableAPlusCompliant(). The raw boolean controlling all this is made private.

[RaitoBezarius]

@andrewimm When you do Parse.Promise.enableAPlusCompliant() in a Cloud Code function, it will fails because the Cloud Code's Parse JS SDK does not have this method.

[andrewimm]

1.6.9 has not been deployed to cloud code yet. It should be up shortly.

[RaitoBezarius]

@andrewimm Do you have a timeframe? Another question while I can, is async / await doable with the Parse.Promise implementation (without A+ compliance), in your opinion? (Of course, it is transpiled to a runtime regenerator with Babel).

[andrewimm]

It should be doable, since I believe Babel's transpile process works with any thenable (but I can sync up with Sebastian to double-check). If it doesn't, we'll make sure it's supported by 1.7.0.
Keep in mind, Parse Promises are A Compliant by default (not A+ Compliant). The only difference between these is how they handle exceptions. A+ catches an exception, A bubbles it up. The A+ compliance flag shouldn't affect anything related to async/await

[RaitoBezarius]

Thanks for those informations, @andrewimm ! I appreciate. :)

[cfoulston]

I vote A+, really needing some exception handling right now