This article is aimed at people starting out with asynchronous coding in javascript so we would keep things simple by avoiding big words, arrow fu...
For further actions, you may consider blocking this person and/or reporting abuse
Nice article. Good job.
One thing that is worth mention is that callback hell can be avoided even if you are "stuck" in an environment that doesn't support promises or async/await. You can always use a function reference instead of an anonymous function.
The game example could look like this:
As someone who doesn't regularly code JS, this was a very helpful primer for these features. Thanks!
Glad to hear that Zeke! 🙂
In the last example, do you really need
in each function, or you can simply return?
By the way, great article!
I think the author was returning those
Promise
s explicitly here to illustrate the point of being able to "get the value out of" thePromise
using theawait
keyword, without having to jump through the normal.then(fn)
hoops. An alternative (usually considered to be more idiomatic) way to write the return statements would have beenreturn Promise.resolve(newScore);
.However, without any "real" async logic in those functions, you could indeed simply return and it would preserve the current behaviour; you can
await
a regular value just fine (i.e.let x = await 5
is valid syntax). As far as I'm aware it can potentially affect the order in which things are processed within the current iteration of the event loop, but that won't observably influence things in most cases, including this one.For completeness' sake, we could take things one step further by making the
level
functionsasync
as well. Anasync
function will always return aPromise
implicitly, so the following are functionally equivalent:This way, we can leave the explicit
Promise
s out, but still benefit from the asynchronous flow.To make the asynchronous behaviour clearer, we could introduce a "wait" function as well, which does nothing more than resolve the
Promise
it returns after the passed amount of milliseconds:If you run this code (e.g. paste it into your console and press enter), you'll see that it runs just as the code in the article, the difference being it has 500ms pauses in between the log messages (the number 500 coming from the value that is passed to
wait
in each case).Note that if you were to remove the
await
keywords in thelevel
functions, that would take away the 500ms pause in that spot. Thewait
function would still be called, but the engine is not instructed to wait for the returnedPromise
to resolve before continuing, so it will just move on to the next statement immediately.I couldn't have explained this question better @Joep 😀Thank you 🙏
My pleasure!
Well done!
Thank you 🙌
I've been struggling to wrap my head around promises and this article made it very clear with your example. Time to go write something with async/await 😀
Thank you Andrew, good luck ✌️
Good and perfect!
Thanks José 🙌
Nice article, very succinct and concise.
Yay! Learnt a new word, now I have to use it! 🎉🎉
Glad you found it succinct Luis 🤓
To anyone exploring asynchronous Javascript programming, also take a look at Observables, in the Rxjs library.
Thank you for this well written article. I am sure many will find it useful.
Thanks Jochem! :)
Really useful! Thank you!
I'm happy that you found this helpful.
You have explained this really well. 👌
Thank you Sunil 🙌
Thanks for the article! However, a high-order function is a function that accepts another function as its parameter or returns one. A callback function is a function that gets passed as a parameter.
Hey varsanyid, nice catch! 🙌Corrected the typo, thanks for pointing 😀
Your callback examples are not async or am I missing something?
Hi Alwyn, the examples are asynchronously executed indeed, just that for the simplicity's sake our example level functions call the callbacks instantly. I have not introduced a setTimeout or a ajax call inside the functions but you can play around and see that even if you do, they work perfectly.
Here's an example demonstrating that
I realize I'm a bit late to the discussion, but, since this is a fairly popular article and I believe many will be using it as a reference in the future, I chose to write this comment anyway.
Also, keep in mind, I am far from a JS expert, it is entirely possible for me to get something wrong or misinterpret the original article. Then again, if I misinterpreted it, who knows how many others might misinterpret it as well.
With all that said, Alwyn is 100% percent right, the callbacks in the article are not asynchronous and, if you think about it, they really shouldn't be. As stated in the article, a callback is simply a function passed as an argument to another function. It's just like any other argument a function can get. It makes no sense for a callback to be magically asynchronously called just by being there. We would not expect an argument of type
Number
to make anything async, so why should a function be any different?Siwalik, all that is called asynchronously in the code you provided as an answer to Alwyn's question is the first argument of the
setTimeout
function. This function creates an event and attaches the arrow function to it. This arrow function is then called after the event is settled (5 seconds later). The functionsstartGame
,levelOne
andcallback
are all called synchronously. The only thing making the code appear asynchronous is the event you created withsetTimeout
and this has nothing to do with callbacks.A good example of proving the synchronous and disproving the asynchronous nature of your original functions is this one:
Notice how
'After callback'
and'Done with callback'
are printed before'After levelOne'
, proving that the callback call is indeed synchronous.Turns out this 'callbacks being asynchronous' thing is a common misconception. Take a look at this stack overflow thread for more information.
Again, sorry if you knew all of this and I just misunderstood your words.
Hi @Filip, I appreciate you for taking the time and explaining this in detail.
I realise setTimeout isn't asynchronous but I've naively used it to mock how an async call would actually behave, didn't realise people starting out might get confused thinking setTimeout has to do anything with async.
Update: I went up and replaced the setTimeout I wrote in @Alwin's reply with an actual API call with delay, for correct depiction of javascript's working. :)
Do not forget to write code in es7+ way :-D Great article.
Pretty decent post. Actually I've never see any cleaner guide to resolve callback helll like this. Kudos!
Appreciate that Tu! Thanks 🙌
I love this post .. Everything is clear. Thanks
cool. Thanks