0

For a side project I'm working on, and for the sake of learning some more JS, I was playing with the YouTube API examples, trying to see how they work.

In Google's own documentation for getting playlists for a given YT channel we have the following asynchronous code:

 var channelPlalists = null; 
 function getChannelPlayLists() {
   return gapi.client.youtube.playlists.list({
      "part": [
          "id"
      ],
      "channelId": "UCe3hdN-kzmG97aR3I3xbyJQ", 
      "maxResults": 50
   })
   .then(function(response) {
     channelPlaylists = response;
   },
   function(err) { console.error("Execute error", err); });
}

In my case I would like to understand how I can turn this into a synchronous request, meaning that I would like the thread to be blocked until the response hasn't arrived.

How can I do that?

I saw that you can decompose the function above in these two parts:

var request = gapi.client.youtube.playlists.list({
  "part": [
    "id"
  ],
  "channelId": "UCe3hdN-kzmG97aR3I3xbyJQ", 
  "maxResults": 50
})

request.execute(function(response) {
  console.log(response); 
}

however this does not help because now it's the execute() method to work in a non-blocking way.

I am also a bit doubtful that what I'm trying to do is even possible at all, as YouTube API could have been written in a non-blocking way by design, so that could be the only way to use it... but this is just my free speculation.

In the end I know this is the opposite of what people usually ask (how to make your code non-blocking) but sometimes this is how I learn stuff... :)

Redoman
  • 3,059
  • 3
  • 34
  • 62
  • 1
    But why do you purposefully want to block the thread and make your whole app unresponsive? It doesn't make sense o_O – Jeremy Thille Jul 29 '21 at 15:06
  • `gapi.client.youtube.playlists.list()` returns a Promise. What you can do is write "synchronous" code by using `async`/`await`. It's still not going to freeze the browser but at least you don't have to use callbacks. You should learn how to do *that*, not how to do deprecated stuff, even if it were possible here. –  Jul 29 '21 at 15:07
  • @JeremyThille I'm just trying to keep things simple as I'm learning, especially I'd like to keep the execution flow as linear as possible. Also, the google examples show asynchronous code, but I don't want to learn the examples by hearth. I want to see how both asynchronous and synchronous version for the same piece of code are written. – Redoman Jul 30 '21 at 01:41
  • But you can't make a network request synchronous. They are asynchronous by nature. All you could do against it is make your CPU process an infinite loop until the network request ends, just to keep it busy and make your users angry against your unresponsive application that crashes their browser. It is very efficient if your goal is to lose customers. The usual way of learning is "How do I deal with asynchronism?", not "How do I purposefully make my app worse by blocking the thread?" Sounds to me you are learning backwards... – Jeremy Thille Jul 30 '21 at 06:27
  • @JeremyThille what do you mean network request are asynchronous by nature? There are countless examples that come to my mind about network requests blocking the thread they are called from... Even `XMLHttpRequest` can work both in asynchronous and synchronous way (https://mzl.la/379duCz). I just would like the thread to wait for the network request to be complete as it happens with a normal request NOT using Promises. By the way there is not a single predefined path for learning something, so please respect others and their different approaches. – Redoman Jul 30 '21 at 20:45
  • They are asynchronous by nature, because you call another system via the network. You make a call to another machine, then you wait. It takes some time, during which you can't do anything but wait. Synchronous languges like PHP just block everything until the network request completes, which is a disaster performance-wise. Other languages like Javascript allow to not block the thread and use the CPU for other things, until the network request completes. This being said, you are indeed totally free to spend your time learning how to un-optimize your app and maim its performance. – Jeremy Thille Aug 02 '21 at 07:10
  • I think you're bending the terminology to express a different concept of "asynchronicity", which is not what we usually mean in programming when we refer to it. `You make a call to another machine, then you wait. It takes some time, during which you can't do anything but wait`. This is not considered to be an asynchronous request, but the exact opposite. Instead, when we make a network request in a way that we are not bound to wait for it to complete, this is considered an asynchronous request. Adding your own esoteric semantic layer on top of the usual meaning is only adding more confusion. – Redoman Aug 03 '21 at 14:14

0 Answers0