Reputation: 13
I have been reading about asynchronous programming in javascript, and came across callback: Javascript Callback.
I will show two of the examples:
Example 1: Not using callback
function myDisplayer(some) {
document.getElementById("demo").innerHTML = some;
}
function myCalculator(num1, num2) {
let sum = num1 + num2;
myDisplayer(sum);
}
myCalculator(5, 5);
Example 2: Using callback
function myDisplayer(some) {
document.getElementById("demo").innerHTML = some;
}
function myCalculator(num1, num2, myCallback) {
let sum = num1 + num2;
myCallback(sum);
}
myCalculator(5, 5, myDisplayer);
My questions:
The problem with the example (here Example 1), is that you cannot prevent the calculator function from displaying the result.
What is preventing the calculator function from displaying the result in Example 2? Since both of the examples is waiting for a calculation, meaning the current thread would not continue before the calculation is done, and the callback seems to be excess.
let sum = num1 + num2
would have been replaced with a call to query a external database.Upvotes: 1
Views: 82
Reputation: 351308
The comment you quoted wants to emphasise that if you look only at the calculator
function in example 1, you already know that it will call myDisplayer
. But if you look only at the calculator
function in example 2, it is not specified whether or not it will call myDisplayer
. That will only be decided by the caller.
In example 2, the calculator is not specifically designed to display the result. The caller can still instruct the calculator to do so (like in example 2), but the calculator can also be used (without changing it) to not display the result. And that is the big difference.
This has nothing to do with threads, and not even with synchronous versus asynchronous code.
This is an example of separation of concern: the calculator should not be hard-wired to display the result. It should leave that decision to the caller and just concentrate on the calculation.
The power of the callback parameter is that the caller decides what should happen with the result. Consider this example 3:
function myStorer(some) {
localStorage.setItem("sum", some);
}
function myCalculator(num1, num2, myCallback) {
let sum = num1 + num2;
myCallback(sum);
}
myCalculator(5, 5, myStorer);
Note especially how myCalculator
has not been modified compared with example 2, yet it does not display the result now. It stores it in local storage.
That is the power of passing a callback as argument.
Upvotes: 1
Reputation: 944441
I'll say up front that W3Schools is really not great. They have been around for a long time and have good SEO so a lot of people will find their content. I do not recommend it, and their explanations don't seem to be landing well for you. MDN is generally a better bet.
What is meant by the comment
They mean that the behaviour "do a calculation and then display it" is baked into the myCalculator
function.
What is preventing the calculator function from displaying the result in Example 2?
Nothing, but if you passed a different function into the third argument of myCalculator
version 2 then that function could do something other than displaying the result.
Since both of the examples is waiting for a calculation, meaning the current thread would not continue before the calculation is done, and the callback seems to be excess.
It is, and if you were trying to solve the problem of synchronously adding two numbers and returning a result then you'd normally use a return
instead of a callback.
However, this is a simple example designed to demonstrate how callbacks work. It isn't designed to be an example of an ideal use case for them.
Wouldn't these two examples do the same thing, meaning there's no need for callback in this case?
The point they are making is that you could pass a different function to myCalculator
and do something different with the result in version 2.
Upvotes: 1