0

I have a code block something like this:

function printData(response) {
  response.json()
          .then(data => console.log(data.name));
}

const fetchedData = fetch("http://localhost:3000/url");

fetchedData.then(printData);

console.log("First console output");

This code executes directly whenever the page loads. My endpoint fetch("http://localhost:3000/url") returns response after 200ms.

Since the XHR will resolve after all global execution context finishes, it should get out of the call stack. But does global execution really gets out of the call stack? Because there is still a task to process, still we need to run printData function after request resolves. Will global execution context wait until request resolves or does it get out of the call stack even there are some requests still being fetched?

Flow is like this;

  1. printData set to memory
  2. fetchedData variable set to memory and browser feature xhr initiates the request.
  3. printData assigned to fetchedData promise.
  4. console output.

Now global execution context finishes but still, we are waiting for the response of the fetch("http://localhost:3000/url");. Will the global execution context get out of the call stack or will it wait the request to fulfill?

Burak Güneli
  • 114
  • 1
  • 11
  • JavaScript doesn't really have a "global execution context" that lives in the stack. By "global execution context" I assume you mean you're referring to the top-level "main" or "root" function? – Dai May 17 '20 at 09:18
  • I recommend you read this QA posting (it's all good, but the relevant part is the first 2 paragraphs of the accepted answer): https://stackoverflow.com/questions/9015836/why-doesnt-javascript-need-a-main-function – Dai May 17 '20 at 09:20
  • JavaScript is full of special-cases - one such example is that any `var` variables and `function` declarations in the "root" or "main" code area is not actually considered a "local variable" (as it would in most other languages) but is _promoted_ to being a property-member of the `window` object (this doesn't apply to `let` variables and `const` values though - as those are always considered local to their enclosing scope). – Dai May 17 '20 at 09:21
  • ...so your `function printData` will actually be accessible as `window.printData` - and you can see this in your JavaScript debugger. – Dai May 17 '20 at 09:23
  • That's an excellent explanation, thanks! But I have one more question. The call stack is last in first out and initially "main" or "root" will be on the call stack. So far as I understand "main" or "root" will always be available until a page reload or the user closes the browser tab. But also until the call stack empty, we can't move tasks from the microtask queue or callback queue. If "main" will always be in the call stack, how can we pull new tasks to call stack from the callback queue or from the microtask queue? @Dai – Burak Güneli May 17 '20 at 10:00
  • "But also until the call stack empty, we can't move tasks from the microtask queue or callback queue. If "main" will always be in the call stack, how can we pull new tasks to call stack from the callback queue or from the microtask queue?" - you're operating on an incorrect assumption that "`main` will always be in the call stack" - this isn't the case: after a page's "root" JavaScript function finishes (i.e. at the end of the last ` – Dai May 17 '20 at 10:05
  • "how can we pull new tasks to call stack from the callback queue or from the microtask queue?" - you don't. That's the browser's scheduler's job and it depends entirely on what engine/context/library feature implemented the `Promise` - and the term "microtask queue" is a specific technical term that I don't think should be used when writing scripts in general (the term was introduced in ES8 which post-dates the introduction of `Promise`). – Dai May 17 '20 at 10:11
  • Now I get the concept. Thanks for your responses @Dai – Burak Güneli May 17 '20 at 10:48

0 Answers0