Repository navigation
Improving JavaScript API #73
Description
Once we settle down the dust from the new API changes from @nkallen's work, I'd like to revisit our JS API. Was talking to @cowboy today and he brought up promises and I totally agree that we should support them in some fashion.
Our convenience API may be best suited for this completely optional feature.
Thoughts?
Activity
nkallen commentedon Jun 25, 2013
I've played with Q which is ok. It has a nice feature that allows you, with the same function, to return either a promise or act like a node CPS. So it's worth considering. My experience with it, though, is that it saved only a tiny bit of boilerplate code (constantly checking
if (error) return callback(wrap(error))) at the cost of another API to learn. It often doesn't eliminate callback nesting since you need intermediate values in the innermost callback.tbranyen commentedon Jun 25, 2013
It's not about eliminating callbacks it's about providing an alternative control flow, which to some doing parallel or frequent async operations can mean more succinct code.
It was also proposed, as a possibility, to make a nodegit-promisify library that wraps the nodegit module and then exposes a Promise-based API.
faceleg commentedon Jun 25, 2013
+1 for nodegit-promisify
tbranyen commentedon Jun 26, 2013
Another cool improvement that could be made to the JavaScript API is implementing Streams.
tbranyen commentedon Mar 23, 2014
Closing in favor of keeping nodegit raw.