Proposal: The future of Parse.Promise about parse-sdk-js

[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

[lrettig]

FYI, I noticed that enabling A+ compliance for Parse Promises breaks at least one core piece of code in ParseReact: cf. parse-community/ParseReact#161.

[JeremyPlease]

If we back Parse.Promise with native promises, then would we be able to use process.on('unhandledRejection'...?

[andrewimm]

@JeremyPlease if you could guarantee that you clients all use the native promise and not a polyfill, then yes. But for all clients where we still add the custom implementation because Promise is not supported, we're not going to add an intrusive global event, so it may not be the best thing to depend on. As a developer, I find it's much easier to lint against missing handlers than to use a global catch-all.

[JeremyPlease]

@andrewimm Thanks for the quick response!
I mostly want to be able to catch unhandledRejection within Parse server (open source) cloud code. So, support within node wouldn't be an issue. I understand that this sdk is shared on browser clients as well.

Linting against missing handlers sounds like a great idea, but I don't see how this would work when returning promises that return and bubble up to a fail/error/catch handler in another file. If you have any suggestions on how linting would work for promises across files, please let me know.

I'll try to take a look at ParsePromise.js to see what kind of effort there would be use native promises when available and polyfill as needed.

[recrsn]

What is the status of these?

[flovilmart]

@JeremyPlease any chance you made progress on that? as it'S 2018, perhaps the promise library should be provided by a 3rd party no?

[JeremyPlease]

@flovilmart

The Parse JS SDK is built with babel transform runtime which will polyfill Promise. So, we should be able to use Promise without any 3rd party library.

I just made a quick attempt to use native promises. Unfortunately, this breaks all kinds of tests and functionality that rely on ParsePromise resolutions to happen synchronously.

The current ParsePromise implementation executes the promise callbacks immediately. However, native promises will execute the callbacks on "nextTick" (or a similar approach in browsers). So, tests like this one will fail with native promises since it expects the .then callback of the promise to be executed immediately when p.resolve(); is called. It's likely that some actual functionality could be broken beyond just how tests are written.

My recommendation: keep ParsePromise as-is. If there is a big want/need to switch to a native promise implementation I think it should be done as a v2 release.

[flovilmart]

rely on ParsePromise resolutions to happen synchronously.

Thats, unfortunate and I guess it would introcude a lot of changes.

I think it should be done as a v2 release.

That's reasonable and would be very nice!

[recrsn]

My recommendation: keep ParsePromise as-is. If there is a big want/need to switch to a native promise implementation I think it should be done as a v2 release.

This is unfortunate.

However, as promises and async/await are slowly becoming ubiquitous, it will be beneficial for all to be standards compliant. I'm not sure how the synchronous resolution goes along the async/await code.

I'm can help out in porting some of the code, if it is decided to go ahead in this direction.

[flovilmart]

@agathver we’re not against refactoring the code to leverage native promises. As it’s been mentioned, many tests will have to be re-written and we can assist anyone wanting to tackle this task :)

[JeremyPlease]

Yeah, definitely unfortunate.

It might be good to have ParsePromise subclass Promise (class ParsePromise extends Promise) but babel doesn't support subclassing builtin classes. There are some ways to work around it though.

The biggest challenge will be modifying tests to properly handle asynchronous resolution of promises and then ensuring there isn't anything else in the Parse JS SDK or Parse Server that is unknowingly taking advantage of the current synchronous behavior.

@agathver Please feel free to take a stab at this and post any updates here 😃

[EPILock]

Team, is any work in progress on this?

Thanks

[flovilmart]

It seems that it doesn’t really need to be done at that time as no one is rushing for an implementation. Feel free to take a stab at it

[dplewis]

Closed via #620

As of 2.0 of this SDK Parse.Promise has been removed.