First, why wrap your second example in try {} catch {} but not the first? The second example (final example from the article) seems like it was intentionally made more complicated to prove its point, but it could just be unfamiliarity. Node idioms are just different from other environments and it takes time to get a good feel for them.
(Edit: noticed that the article does it this way.)
How about just:
function insertCollection(collection, cb) {
if (collection.length === 0) cb(null);
else db.insert(collection[0], function (err) {
if (err) cb(err)
else insertCollection(collection.slice(1), cb)
}
}
That's hardly much more complex, and as a bonus won't lock up your whole program while db.insert() is working. You could use something like my own library Seq() too:
var Seq = require('seq');
function insertCollection (collection, cb) {
Seq.ap(collection).seqEach(function () {
db.insert(c, this);
}).seq(cb).catch(cb)
}
That is, if you actually want the inserts to go sequentially. Usually you want them to go in parallel with say a maximum of 10 pending requests:
var Seq = require('seq');
function insertCollection (collection, cb) {
Seq.ap(collection).parEach(10, function () {
db.insert(c, this);
}).seq(cb).catch(cb)
}
I don't see any "fundamental issue" with node here. It's just a very new ecosystem and the idioms and libraries are rapidly evolving.
Well, sorry to be snarky, but you couldn't have supported my point better.
Both you and the article author (where the code snippets are from) missed this critical detail during the first iteration. And not on some complex, esoteric problem but on one of the most basic language constructs.
I blame neither of you, I only ask that we please not discount the extra complexity.
Ah, your point makes much more sense now. Yes, the author had some overly complex examples, but I'm optimistic about using user-space libraries to handle flow control without having to add new language primitives.
Comments
First, why wrap your second example in try {} catch {} but not the first? The second example (final example from the article) seems like it was intentionally made more complicated to prove its point, but it could just be unfamiliarity. Node idioms are just different from other environments and it takes time to get a good feel for them.
(Edit: noticed that the article does it this way.)
How about just:
That's hardly much more complex, and as a bonus won't lock up your whole program while db.insert() is working. You could use something like my own library Seq() too: That is, if you actually want the inserts to go sequentially. Usually you want them to go in parallel with say a maximum of 10 pending requests: I don't see any "fundamental issue" with node here. It's just a very new ecosystem and the idioms and libraries are rapidly evolving.why wrap your second example
That's hardly much more complex
Well, sorry to be snarky, but you couldn't have supported my point better.
Both you and the article author (where the code snippets are from) missed this critical detail during the first iteration. And not on some complex, esoteric problem but on one of the most basic language constructs.
I blame neither of you, I only ask that we please not discount the extra complexity.
Ah, your point makes much more sense now. Yes, the author had some overly complex examples, but I'm optimistic about using user-space libraries to handle flow control without having to add new language primitives.