Real? Bower?

[clavecoder]

@jeffbcross, will prophesy be used by Angular 2.0? Have you considered publishing on npm and bower? If not, can you suggest any other es6 promise complaint deferred implementation? It doesn't make sense to pull in traceur.

[jeffbcross]

I'm not sure of any other implementations, though I remember seeing some when we were determining what to use for Angular 2. This library actually just uses the ES6 Promise from the browser or Traceur, and adds a small deferred wrapper around it (which we're not sure we want to keep), and adds the ability to mock and synchronously flush the promise.

I'm not sure how much we'll use this in Angular 2, it depends on how painful it is to test against native promise.

[clavecoder]

It's just what I want. I think Deferred makes promises much easier to manage in libraries. I'd love to learn how I'm wrong. Are there any good examples of managing ES6 promises directly as properties?

Sent from my Windows Phone

---

From: Jeff Crossmailto:notifications@github.com Sent: ‎11/‎11/‎2014 12:11 PM To: angular/prophecymailto:prophecy@noreply.github.com Cc: Kenneth Brubakermailto:kennethbrubaker@hotmail.com Subject: Re: [prophecy] Real? Bower? (#6)

I'm not sure of any other implementations, though I remember seeing some when we were determining what to use for Angular 2. This library actually just uses the ES6 Promise from the browser or Traceur, and adds a small deferred wrapper around it (which we're not sure we want to keep), and adds the ability to mock and synchronously flush the promise.

I'm not sure how much we'll use this in Angular 2, it depends on how painful it is to test against native promise.

---

Reply to this email directly or view it on GitHub: https://github.com/angular/prophecy/issues/6#issuecomment-62580395

[jeffbcross]

@benjamingr has thoughts on the deferred pattern

I think the biggest argument for doing everything inside ES6 resolver fn is throw safety. E.g. something goes wrong inside, it gets handled by the promise's reject chain, whereas the deferred pattern leaves it up to the application to handle errors.

[benjamingr]

@jeffcross I'm sorry but I don't understand the discussion.

@kenbrubaker do you mind clarifying what you mean by Deferred?

[jeffcross]

I just realized that "Jeff Cross" is not the most original name in the world. @jeffbcross, I think this was meant for you:

@benjamingr said:

I'm sorry but I don't understand the discussion.

I apologize for chiming in. I was very confused but also didn't want to slow progress on this issue.

-JC

[jeffbcross]

Ha, thanks other Jeff Cross @jeffcross

[ilanbiala]

Back to the original question, is this ready to be used? Can it be published on bower?

[clavecoder]

Here's an article the explains the deferred object with references to the CommonJS Promises/A spec:

The problem is that the ES6 spec only defines the promise object which makes it hard to multiplex. Sorry, I come from the .NET tradition and like my Task class. It looks from the reply from @jeffbcross that not having deferred is more "safe" since it is more likely to force people to call reject(). I like having Deferred() for libraries, where, of course, deferred.promise() is returned eventually.

The problem is there doesn't seem to be a minimal ES6 extension out there that just adds Deferred. I'm hoping that angular/prophecy can be that repo.

[benjamingr]

@kenbrubaker why do you think it makes it hard to multiplex?

In C# you have to use TaskCompletionSource yourself a lot less than you have to use new Promise( in JS. The main advantage of the Promise constructor over deferreds is that it's throw safe, so if your constructor accidentally throws (let's say on a faulty JSON.parse) the exception doesn't get swallowed.