Promises in core?

[pocesar]

I created https://github.com/pocesar/promised-jugglingdb but kinda wasted my time because Jugglingdb is a mess. Does datasource juggler have 'space' for a dual API (promise / callback) in core?

[raymondfeng]

Cool, I’ll take a look first before I can comment.

Thanks,

---

Raymond Feng
Co-Founder and Architect @ StrongLoop, Inc.

StrongLoop makes it easy to develop APIs in Node, plus get DevOps capabilities like monitoring, debugging and clustering.

On Jul 16, 2014, at 1:10 PM, Paulo Cesar notifications@github.com wrote:

I created https://github.com/pocesar/promised-jugglingdb but kinda wasted my time because Jugglingdb is a mess. Does datasource juggler have 'space' for a dual API (promise / callback) in core?

—
Reply to this email directly or view it on GitHub.

[pocesar]

alright nice, take a look at the rebased tree instead, I gave up jugglingdb because of the author comment about how promises are "syntax sugar"

[raymondfeng]

What's your take between Promise and Generator?

• http://strongloop.com/strongblog/promises-in-node-js-with-q-an-alternative-to-callbacks/
• http://strongloop.com/strongblog/how-to-compose-node-js-promises-with-q/
• http://strongloop.com/strongblog/comparing-node-js-promises-trycatch-zone-js-angular/
• http://strongloop.com/strongblog/node-js-callback-hell-promises-generators/

[bajtos]

In my opinion, Promises are sort of a must-have.

Since LoopBack and Juggler are running in the browser now, we need a paradigm that works across all semi-modern browsers. I am not following the implementation of ES6 features in different browsers, but I would expect it will take some time before generators can be safely used on the web.

AngularJS, which is the front-end MVC we support, is promise-based. We will have to implement promise-based API for loopback when building an isomorphic version of LoopBack SDK for AngularJS.

[pocesar]

@raymondfeng I think generators are just as needed in asynchronous programming as promises, since they play along very well (yield promises + chain generators). While promises provide a generic interface (then/catch/finally), generators need "something" else to glue them together (like using co or genny.js). While there are no support for generators in browsers (function *(){} but "kind of" generators ES5 shims), but there wide Promise support (namely through bluebird, that has a really good browser support) in both Node and the browser, it's a sure technology to use. that's my take :)

@bajtos yeah, I agree. I use Angular in my day-to-day programming, and you just can't ignore proper handled async code anymore. Although Angular is STILL missing a way to run() async code (it ignores the returned value of the module.run call), it will come someday. people tend to prefer AMD (usually through require.js) in the browser because you can scatter your code through multiple files and load them at will. I'm inclined to always provide APIs that can handle promises, even if you just plan to return an array from your synchronous function, just because recently I had to perform an $http call inside Angular run method and found myself having to resort to manually bootstraping my app because of lack of async support in it, ironically...

[faceleg]

👍 I'm jumping up and down in my seat reading this. 🏩

[pandaiolo]

o/ promisify all the things !

[bajtos]

Related: strongloop/loopback#418

[pulkitsinghal]

Just curious, where do promises for the core stand right now in the queue?

[bajtos]

Closing in favour of strongloop/loopback#418, which is already in progress.