StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
4506306
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
6
CommunityOwnedDate
CreationDate
2010-12-22T05:02:31.030
FavoriteCount
0
LastActivityDate
2011-06-22T15:17:43.080
LastEditDate
2011-06-22T15:17:43.080
LastEditorUserId
157247
OwnerUserId
157247
ParentId
4506240
PostTypeId
2
Score
85
ViewCount
0
LastEditorDisplayName
text
Body
If the callback is defined in the same scope the loop is defined in (which is frequently the case), then the callback will have access to the index variable. Leaving aside NodeJS particulars for a moment, let's consider this function: <pre><code>function doSomething(callback) { callback(); } </code></pre> That function accepts a callback function reference and all it does is call it. Not very exciting. :-) Now let's use that in a loop: <pre><code>var index; for (index = 0; index < 3; ++index) { doSomething(function() { console.log("index = " + index); }); } </code></pre> (In compute-intensive code — like a server process — best not to literally do the above in production code, we'll come back to that in a moment.) Now, when we run that, we see the expected output: <pre><code>index = 0 index = 1 index = 2 </code></pre> Our callback was able to access <code>index</code>, because the callback is a closure over the data in scope where it's defined. (Don't worry about the term "closure," <a href="http://blog.niftysnippets.org/2008/02/closures-are-not-complicated.html" rel="noreferrer">closures are not complicated</a>.) The reason I said it's probably best not to literally do the above in compute-intensive production code is that the code creates a function on every iteration (barring fancy optimization in the compiler, and V8 is very clever, but optimizing out creating those functions is non-trivial). So here's a slightly reworked example: <pre><code>var index; for (index = 0; index < 3; ++index) { doSomething(doSomethingCallback); } function doSomethingCallback() { console.log("index = " + index); } </code></pre> This may look a bit surprising, but it still works the same way, and still has the same output, because <code>doSomethingCallback</code> is still a closure over <code>index</code>, so it still sees the value of <code>index</code> as of when it's called. But now there's only one <code>doSomethingCallback</code> function, rather than a fresh one on every loop. Now let's take a negative example, something that doesn't work: <pre><code>foo(); function foo() { var index; for (index = 0; index < 3; ++index) { doSomething(myCallback); } } function myCallback() { console.log("index = " + index); // <== Error } </code></pre> That fails, because <code>myCallback</code> is not defined in the same scope (or a nested scope) that <code>index</code> is in defined in, and so <code>index</code> is undefined within <code>myCallback</code>. Finally, let's consider setting up event handlers in a loop, because one has to be careful with that. Here we will dive into NodeJS a bit: <pre><code>var spawn = require('child_process').spawn; var commands = [ {cmd: 'ls', args: ['-lh', '/etc' ]}, {cmd: 'ls', args: ['-lh', '/usr' ]}, {cmd: 'ls', args: ['-lh', '/home']} ]; var index, command, child; for (index = 0; index < commands.length; ++index) { command = commands[index]; child = spawn(command.cmd, command.args); child.on('exit', function() { console.log("Process index " + index + " exited"); // <== WRONG }); } </code></pre> It seems like the above should work the same way that our earlier loops did, but there's a crucial difference. In our earlier loops, the callback was being called immediately, and so it saw the correct <code>index</code> value because <code>index</code> hadn't had a chance to move on yet. In the above, though, we're going to spin through the loop before the callback is called. The result? We see <pre><code>Process index 3 exited Process index 3 exited Process index 3 exited </code></pre> This is a crucial point. A closure doesn't have a copy of the data it closes over, it has a live reference to it. So by the time the <code>exit</code> callback on each of those processes gets run, the loop will already be complete, so all three calls see the same <code>index</code> value (its value as of the end of the loop). We can fix this by having the callback use a different variable that won't change, like this: <pre><code>var spawn = require('child_process').spawn; var commands = [ {cmd: 'ls', args: ['-lh', '/etc' ]}, {cmd: 'ls', args: ['-lh', '/usr' ]}, {cmd: 'ls', args: ['-lh', '/home']} ]; var index, command, child; for (index = 0; index < commands.length; ++index) { command = commands[index]; child = spawn(command.cmd, command.args); child.on('exit', makeExitCallback(index)); } function makeExitCallback(i) { return function() { console.log("Process index " + i + " exited"); }; } </code></pre> Now we output the correct values (in whatever order the processes exit): <pre><code>Process index 1 exited Process index 2 exited Process index 0 exited </code></pre> The way that works is that the callback we assign to the <code>exit</code> event closes over the <code>i</code> argument in the call we make to <code>makeExitCallback</code>. The first callback that <code>makeExitCallback</code> creates and returns closes over the <code>i</code> value for that call to <code>makeExitCallback</code>, the second callback it creates closes over the <code>i</code> value for that call to <code>makeExitCallback</code> (which is different than the <code>i</code> value for the earlier call), etc. If you give <a href="http://blog.niftysnippets.org/2008/02/closures-are-not-complicated.html" rel="noreferrer">the article linked above</a> a read, a number of things should be clearer. The terminology in the article is a bit dated (ECMAScript 5 uses updated terminology), but the concepts haven't changed.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POunderstanding the concept of javascript callbacks with node.js, especially in loops
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. UST.J. Crowder
UserOwnerUserId
1. UST.J. Crowder
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POunderstanding the concept of javascript callbacks with node.js, especially in loops
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTAcceptedByOriginator
CommentsPostId

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.