Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Support promises API #608

Closed
daleharvey opened this Issue · 14 comments

5 participants

@daleharvey
Owner

I think its sensible to leave this to be one of the last things to be implemented, but supporting promises in our API would be nice

https://gist.github.com/crodjer/5251904

The chances are whatever library alex russell says to use is what should be used

@rymohr

Happy to help with this one. What libraries are you considering?

I personally prefer the additional clarity provided by jquery's done / fail over the basic then call. I've found request.done(cheer).fail(boo) just reads clearer than request.then(cheer, boo).

Just my $0.02. Looks like lots of good libraries listed at http://wiki.commonjs.org/wiki/Promises/A

@calvinmetcalf

@islandr you need to look at the a+ spec mot the a one. I've had luck with RSVP which is pretty complete and promiscus which is nice and small.

@daleharvey
Owner

That reply was a bit short, my explanation

I want a small library that only does promises, nothing else (like using old jquery would have included a bunch of stuff just to get promises, even the new one I would be fairly cautious about). I would like something thats being built with future browser support in mind, so users code wont need to change and theoretically we can just drop the library when browser support happens.

DOMFuture was just a quick off the top of my head thing since Alex is one of the people working on the spec

@calvinmetcalf

As was my response, mainly because I was on my phone at the time promiscuous is nice and small and supports browsers and node, I'm using it in one of my other projects.

DOMFuture looks very nice though seems a bit big but a nice thing about the A+ spec is that any library that implements it (properly) is going to be comparable with any other library that implements it.

@rymohr
@calvinmetcalf

@islandr The Wikipedia article seems to imply that while JavaScript only calls them promises other languages use the two terms interchangeably.

The other issue with DOMFuture (and point towards promiscuous) would be node.js use I'm guessing DOMFuture isn't to good with that.

The really tricky part about switching from callbacks to promises is that a promise can only be used once, so places where a callback is called multiple times can't be switched seamlessly.

@daleharvey
Owner

We wouldnt be switching from one to the other, we would support both, callbacks will still be idiomatic in node and as you mentioned they are needed for onChange etc, all we need to do is change the return

Also the spec that DOMFuture is based off just became part of whatwg - http://dom.spec.whatwg.org/#futures, as far as I can tell it works fine in node, as it uses node for testing

@calvinmetcalf

I meant that it wouldn't work in node because it had a focus on DOM type stuff and lack of package.json

@calvinmetcalf

I only bothered to look in the root my bad.

@DrYSG

I could use this feature today. See issue #821

@neojski
Owner

I'm planning to work on that in the nearest future.

@daleharvey
Owner

Closing in favour #848, instead of doing bit by bit API improvements I would like to get the whole API to a point where we are happy supporting all of it

@daleharvey daleharvey closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.