Light-weight async.parallel for fetcher's single use-case

[jlogsdon]

A solution for #36

Mucked around a bit with rendr-app-template and it seemed to work fine.

[spikebrehm]

Cool, thanks. It would be great to pull this little snippet into its own NPM module, but until we can get Browserify working for better packaging (so each app doesn't have to explicitly list it as a dependency), this looks reasonable.

[spikebrehm]

Why set this to empty?

[spikebrehm]

Oh, this is an alternative to breaking out of the loop?

[spikebrehm]

I think it makes sense to bail early and stop iterating through the callbacks, in case we're doing some extra work in the tasks that we should avoid.

[jlogsdon]

I can see that. Would be nice if _.each had an easy way to break out of loops.

[jlogsdon]

Actually, breaking out won't really help. The asynchronous nature means we could already be through the loop before an error occurs. Checking for it would require tracking the state somehow, and seems like over engineering the problem.

I could see not clearing the callback and continuing to collect results so it fires off again at the end. That may be strange behavior, though, as the callback could get used more than once (even more than twice).

[spikebrehm]

I'll merge this in for the next minor version release, because removing
the async dependency may break the build step of any apps that try to
bundle it.

[jlogsdon]

Yeah, rendr-app-template will need an update to the Gruntfile (although it is locked to the rendr release it works with, so that's good).

[jlogsdon]

Cool, thanks. It would be great to pull this little snippet into its own NPM module, but until we can get Browserify working for better packaging (so each app doesn't have to explicitly list it as a dependency), this looks reasonable.

Sounds good.

A quick note on pretty much all of your comments (which I will address individually): the implementation I made is an exact drop-in for async.parallel, mimicking all of its behavior. If we kept this as a local-only replacement I'd be fine with making the behavior even more specific, but if we want to NPM-ize it later I think it makes sense to keep the functionality as close to async's as possible.

[c089]

@jlogsdon sorry this was open for so long - if you're still interested in working on this I promise we'll get to it this time :) Browserify is now in as well, so you could do the npm module spike suggested. Otherwise please let me know so I can close here (trying to manage the remaining open PRs).