Adding Promises/A+ Support to enyo.Async?

32 views
Skip to first unread message

Doug Reeder

unread,
Jul 10, 2015, 1:58:41 PM7/10/15
to enyo-dev...@googlegroups.com
Has anyone done any work on adding the Promises/A+ API to enyo.Async? That would greatly ease the transition to ES6 Promises.


Doug Reeder
reed...@gmail.com
https://ello.co/dougreeder
https://twitter.com/reeder29
http://reeder29.livejournal.com/

http://hominidsoftware.com









Pre101

unread,
Jul 10, 2015, 2:55:10 PM7/10/15
to enyo-dev...@googlegroups.com, reed...@gmail.com
Promises would be a nice addition to enyo.Async, I think.  The issue (I think) is that we'd have to bundle a promise wrapper for platforms that don't support promises.  Maybe someone can chime in with a way to handle that?

Roy

Doug Reeder

unread,
Jul 11, 2015, 2:12:19 AM7/11/15
to enyo-dev...@googlegroups.com
There appear to be two routes we could take:

A) Simplistic. Implement a .then(resolvePromise, rejectPromise), which works like .response(resolvePromise) plus .error(rejectPromise)
This would not comply with the Promises/A+ .then(), but would be a “thenable” which interoperates.

B) Conformant. Implement a .then(resolvePromise, rejectPromise), which conforms to Promises/A+. Asyncs can go from fulfilled to rejected and vice versa, via .fail() and .recover. Thus, functions passed to resolvePromise and rejectPromise functions would need to be segregated from functions passed to response and error, and we’d need new logic: if onFulfilled is called onRejected must not be (and vice versa).


As I see it, Promises have three main advantages over Asyncs:
1) Exceptions thrown inside Promises cause the promise to be rejected.
2) Promise.all() and Promise.race() allow parallel executions
3) Familiarity for other Javascript programmers [eventually]


I think option A) is the sensible one. Implementing a conformant .then() doesn’t help with 1). IIRC, “thenables” may be passed to Promise.all(), so A) is just as good. (If Promise.all() only takes real Promises, Asyncs could be wrapped with a Promise.) With either option, we only get familiarity with .then(), not the rest of the Promise interface.


We don’t need to include a polyfill for Promises in Enyo; that’s actually orthogonal. I expect Enyo apps will start including https://github.com/jakearchibald/es6-promise (I’ve already added it to Serene Notes.)

Apps could then update Enyo and add a Promise polyfill, then implement new code using Promises. As time for refactoring becomes available, old code could be refactored, replacing Asyncs with Promises, gaining the advantage of exception-catching and easier maintenance by programmers new to Enyo.

Pre101

unread,
Jul 11, 2015, 2:46:26 AM7/11/15
to enyo-dev...@googlegroups.com, reed...@gmail.com
Would an option C where you pass in your promise library (or perhaps 'true' to use ES6?) during initialization of Async and we use that for creating the promise work?

Doug Reeder

unread,
Jul 11, 2015, 11:27:24 AM7/11/15
to enyo-dev...@googlegroups.com
That is certainly implementable, but I don’t see it as very useful. In my code, I have several interfaces that are defined to return Asyncs; only one requires an Async to be passed in. If the code that creates an Async is Promise-aware, it could just create a Promise.
> --
> You received this message because you are subscribed to the Google Groups "Enyo Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to enyo-developme...@googlegroups.com.
> To post to this group, send email to enyo-dev...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/enyo-development/06986e6b-e4db-4b26-bdb8-593384eb35a8%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages