mtscout6
commented
7 years ago So this gets interesting because there's a few ways to do this. First is to be transparent about paging. So, something like:
for (let page of request()) {
for (let item of page.items) { ... }
}Can't say that I'm a huge fan of that approach. Though if you move to using the newer for await support from Babel as proposed with the async generator transform and outlined as a tc39 proposal
Then you could do something like this:
for await (let item of request()) {
...
}Though the ES5 equivalent gets really messy:
function forEach(ai, fn) {
return ai.next().then(function (r) {
if (!r.done) {
fn(r);
return forEach(ai, fn);
}
});
}
var item = 0;
forEach(request(), function(val) { item += val.value })
.then(function () {
console.log(item);
});Essentially downstream users that use Babel would be the ones to win here, those not Using Babel would need to wait a few years for the Spec changes to replicate to the different JavaScript interpreters. If we did the async generator approach then we should callout in the docs that Babel is recommended and that we wouldn't support users not using Babel.
@clayreimann Thoughts?
jeanettehead
Would be nice to be able to fetch only a page of repositories, repo commits, and other lists instead of fetching the entire thing every time. Currently they call into _requestAllPages which automatically fetches everything from github, which can take awhile for long lists.
@mtscout6 suggested on gitter that a generator function would be a good way to accomplish this.
If there's a good direction to go in, I can probably work on this.