Asynchronous

What annoys me every time I try use react and do some API fetching is the concept of async and promise - they are just way too abstract (as in every details are abstracted away, so I can't just immediately understand stuff by reading the code).

 

But after 6 months, when I revisited this topic by exploring through some videos, I feel like I finally got the grip of some stuffs. I'm writing this to solidify this understanding and hopefully explain it well enough so that when I come back to it, I can look back at it again. 

 

-- basics -- 

Please ignore some technical inaccuracies, as this is the way I'm understanding as of now.

 

A javascript code runs on a browser. The browser allocates a single core (thread) to read the javascript code, so the code runs in a sequence. However, there are other threads that run concurrently on the side. One of them is setTimeout(), which runs on a Timer thread. You can pass a snippet of a javascript code to that thread by calling a setTimeout() and passing a snippet of code as a parameter to setTimeout. setTimeout() takes two parameters: the snippet of code and delay. setTimeout is going to wait for the amount of delay specified, and pass the snippet of code to a queue. This queue will pop the snippet of code to the single core that reads the javascript code, when the single core no longer has the javascript code to run.

 

The way this 'snippet of code' is encapsulated is as a function. Below, I used anonymous function to minimise the code.

//javascript code to be run
console.log('hello');
setTimeout(()=>console.log('function to be run'), 1000);
console.log('yo');

What happens here is the single core allocated by the browser dedicated to run the javascript code:

- runs 'console.log('hello');'

- calls 'setTimeout()' on the Timer thread, passing a snippet of code and delay **

- runs 'console.log('yo');'

 

On that second line, what happens is that the javascript calls setTimeout on Timer thread by passing (()=>console.log('function') (idk why it's hyperlinked)) and delay (1000) as parameters. So that Timer thread:

- runs setTimeout code on itself

- after 1 second of delay (indicated by 1000 that corresponds to miliseconds)

- queues the function ()=>console.log('function'), which gets called by the javascript thread when there's nothing else to run by that javascript thread.

- ()=>console.log('function') is run.

 

What is surprising as a consequence is that when se do setTimeout(), we are queueing the function that's passed as a parameter (in this case ()=>console.log('function') ) to be called at the end of the whole javascript. Then, the 1000 miliseconds parameter indicates that it at least takes 1 second for the passed function parameter to be called, and if the codes that follow setTimeout take more than 1 second, then the function will only be called after all the codes are executed.

 

--what is asynchronous?--

Now the behaviour we see is that the function is delayed to be called later. This is asynchronous behaviour. To put things into a more concrete term, synchronous, as opposed to asynchronous is that each subsequent code is executed only if previous code is executed fully. So to say that ()=>console.log('function') is asynchronous means that the code (()=>console.log('function') ) is not executed, but the thread moves onto executing other subsequent codes. We can say setTimeout(()=>console.log('function') ,1000) as whole is an asynchronous function call, because it doesn't really get executed by the javascript thread, and even when javascript thread has moved onto other subsequent lines of code, it may as well be a case that setTimeout() is not executed fully by the Timer thread. 

 

Next, we will talk about what promise, async, await are.