Understand Callbacks in Node.js
In this lesson you will learn what callbacks are, how to use them and why we use them in our Node applications. We start with a simple javascript function and build a second function that uses it as a callback to understand the basic operation of a callback. From there, we create a few more functions that help illustrate how using callbacks can help us keep our code legible and organized as well as allowing us to use generic functions that can bring in extra functionality when needed via the callback.
It is understandable why callbacks are introduced, but with native promise support (from version 4, I believe - we have version 7 now) callback's approach should be marginalized.
Yup, agreed. This lesson was recorded when 0.12 was the latest and greatest. Callbacks are still a large part of the existing ecosystem, so it's good knowledge for those new to node.js. Stay tuned for some new lessons on Promises in node.js in the next couple of weeks! Thanks for your feedback!
I'm new to node.js and a relatively new developer in general, so I have a fairly basic question. If welcomeMsg() prints the text and then returns undefined (which we see in our console,) and start calls welcomeMsg, then why doesn't calling start(welcomeMsg) print undefined twice? I thought it would - once for the call to start, which returns undefined, and once for the call to welcomeMsg, which does, as well.
Great question Logan.
When using the console, our interaction with Node is done with a REPL, which stands for Read - Evaluate - Print - Loop. The "Print" portion is the key here. In the REPL interface, it prints the output of whatever you give it and in cases where there is no output, the output is undefined. In the second example, welcomeMsg is called from the start function. The start function doesn't get a return value back, and isn't expecting one because it just executes the function. Had we done something different like
var foo = callback;
console.log(foo);it would have printed undefined as you were expecting.
Another way of stating that might be to say that the REPL interface is tied to the start function. So, it Reads the start function, Evaluates it (or executes it), Prints whatever it got back, then Loops back to the cursor waiting for you to tell it what to do next. Everything that happened within the start function was done inside of Node, and only its return values were available to the REPL.
Hope that makes sense, if not- please let me know!
2:20 transcript - You say that the start function calls the callback and returns immediately, without "waiting" for the status of the callback.. so node is available for the next request, ... but then you proceed to say that if the callback was not merely writing to the console in this example, and was a function that parsed a large file, then start function would hang indefinitely. Does this mean if welcomeMsg() function was parsing a large file etc. start would wait on it ? I understand it does not based on the lesson, just wanted to clarify.
2:20 transcript - You say that the start function calls the callback and returns immediately, without "waiting" for the status of the callback.. so node is available for the next request, ... but then you proceed to say that if the callback was not merely writing to the console in this example, and was a function that parsed a large file, then start function would hang indefinitely. Does this mean if welcomeMsg() function was parsing a large file etc. start would wait on it ? I understand it does not based on the lesson, just wanted to clarify.
Kalpana The video seems to imply that Node is non-blocking in general. I am new to Node but that didn't seem correct to me, so I executed callback functions which were long-running but didn't involve I/O. The instructions ran sequentially as expected.
The article below provides clarity.
https://greenash.net.au/thoughts/2012/11/nodejs-itself-is-blocking-only-its-io-is-non-blocking/
Shout-out to Zork.