Skip to content
This repository

Mine this issue for tickets to transfer to Q-IO for DOM wrappers. (edited) #228

Open
mbriggs opened this Issue March 07, 2013 · 10 comments

5 participants

Matt Briggs Kris Kowal Domenic Denicola itsnotvalid
Matt Briggs

It is really cool how Q provides shorthand for interfacing with node APIs, but would you accept a PR for interfacing with functions taking callbacks that don't pass errors as the first arg? I understand that there is less boilerplate involved, but it is a very common thing when working with front end libraries.

Kris Kowal
Owner

Let’s talk about some specific API’s that we want to make more convenient and see if there’s a pattern we can classify, or if it would be better to make custom wrappers for each.

Some DOM API’s that would obviously benefit from promises are the document.ready promise, XHR (would benefit from Q-JSGI), and IndexDB.

I’ll follow up if I catch a break and can illustrate some of the patterns.

Matt Briggs

Those would all be awesome. I was thinking functions that take callbacks as their last argument, if they call the callback it resolves the promise, if they throw an exception it rejects (although there are a bunch of cases where return false rejects, but that is less consistent). That would cover 99% of client side 3rd party libs. The built-in ones may require more specific wrappers

Domenic Denicola
Collaborator

@mbriggs links to documentation for such libraries would be helpful, as I personally can't recall any libraries that don't allow asynchronous failures, only asynchronous success.

Also, this might be good as a separate package (e.g. q-browser-adapter), especially given the variety out there.

Kris Kowal
Owner

I would venture that q-io and a new q-dom support the cases in combination. My intention is to eventually mirror all the q-io interfaces with browser implementations that’d be automatically selected by https://github.com/montagejs/mr and https://github.com/montagejs/mop. I don’t know whether Browserify supports alternate browser implementation mappings but we’d ideally use the same info in package.json.

I don’t think there’s enough homogeneity among DOM API’s to have a general purpose promise adaptor. There certainly is a degree of homogeneity in each subsystem, like onerror and onsuccess handlers in IndexDB.

Domenic Denicola
Collaborator

Re: alternate browser implementation mappings, yeah, as of 2.0 browserify supports this spec.

itsnotvalid

But with NF* granted first tier support in Q, would it be sensible to make a q-node as well?

Kris Kowal
Owner

@itsnotvalid It would be sensible to factor it out. We may or may not. There’s a tension between effort needed to migrate, having a minimal API surface, and having a convenient and complete API surface. One thing that would help unlock the tension is extensible promise API’s, which come with their own level of madness but are distinctly possible.

Just a single, lonely, little example … but I ran into this problem with Node's readline:

_ = Q.nfcall(read.question, "What's your name? ")
_.then (name) ->
   console.log "name: #{name}"
_.fail (error) ->
   console.log "error: #{error}"

This'll print "error: Elliott", because the first argument to readline.question()'s callback is the user-input; there's no error argument.

Domenic Denicola
Collaborator

I can't see any overriding patterns in the DOM that are making this effort feasible. @ELLIOTTCABLE's case is an interesting one, in Node.js: certain Node.js callback-taking functions are actually proxies for someObject.on('specialEvent', ...), like http.createServer or readline.question, and there's always the fs.exists outlier. I'm not sure it'd be worth providing something specifically for those cases though, especially since people would have to remember to use it. (I.e. the workflow would be "get bitten by Q.nwhatever not working, then use Q.weirdnwhatever" which isn't much better than "get bitten by Q.nwhatever not working, then write a small wrapper yourself.")

As such, I think it'd be best to leave any experimentation here in user space. If people come up with some really compelling libraries around these ideas, we should link to them. @kriskowal, what do you think---time to close this issue, or is there still some productive work we can do here?

Kris Kowal
Owner

I would like to mine this ticket for Q-IO and Q-DOM issues, but this is otherwise closed. We do not plan to build anything special into Q proper.

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.