Problem z callback hell

Cześć!

Podczas niedawnej rozmowy o pracę zostało mi przedstawione zadanie z zagnieżdżonymi funkcjami setTimeout
Zauważyłem że większość materiałów o callback hell skupia się na tym jak ich unikać.
Ja zostałem zapytany o kolejność wywołania console.log'ów wewnątrz nich.
Nie mam, niestety, tego zadania. Znalazłem podobne i wywołuje się zupełnie inaczej niż myślałem:

let a = 0,
  b = 10;

setTimeout(function () {
  a++;
  setTimeout(function () {
    a++;
    console.log("1 Attempt: " + a);
  }, 0);
}, 0);

setTimeout(function () {
  console.log("2 Attempt: " + a);
}, 0);
a = b;

Sądziłem że wynik to będzie : "2Attempt: 10 1Attempt: 11 ale jest inny.
Czy ktoś wytłumaczyłby mi / odeśle do materiałów jak rozwiązywać ?

Filmik powinien troszkę rozjaśnić.

Jeszcze jedno:
https://github.com/jumaschion/You-Dont-Know-JS-1/blob/master/async%20%26%20performance/ch2.md
I jak byś chciał się bardziej zagłębić to ogólnie cała seria tych książek jest spoko.

Obejrzałem sobie powyższe nagranie i przyznam że sporo się dowiedziałem.
Patrzę na zadanie które podał OP i wychodzą mi dwa rozwiązania.

2 Attempt: 11
1 Attempt: 12

lub

2 Attempt: 10
1 Attempt: 12

Czy dobrze rozumiem że wszystko zależy od tego jak szybko "webapi" poradzi sobie z przekazaniem eventu do pętli zdarzeń? Mam na myśli to co jest przedstawione w 13:40.
Wychodzi mi na to że zewnętrzne setTimeout trafią do "webapi" i nie ma gwarancji w jakiej kolejności "webapi" wrzuci callbacki do kolejki zdarzeń.
W praktyce pewnie w 99% pierwsza wersja będzie występować, ale nie ma na tym co polegać.

Czy dobrze rozumiem?

Jeśli chcesz coś wykonać sekwencyjnie, polecam skorzystać z async i await:

function delay(ms) {
	return new Promise(resolve => setTimeout(resolve, ms));
}

async function test() {
    console.log('A');
    await delay(1000);
    console.log('B');
    await delay(1000);
    console.log('C');
}

@Karaczan:
O ile wiem to jest tak jak mówisz, tu też potwierdzają: https://stackoverflow.com/questions/1776239/are-equal-timeouts-executed-in-order-in-javascript

Najpierw wykona się kod

let a = 0,
  b = 10;
a = b;

Po nim a będzie równe 10

później web API 2 kawałki kodu z 2 wywołań setTiemout po kolei do Event Loop

  a++;

i

  console.log("2 Attempt: " + a);

Po nim a będzie powiększone o 1
Po nim jest efekt na konsoli: 2 attempt 11

Nie wiem, czy ogólnie określone API zagwarantuje sekwencyjne wejście i wyjście eventów. Najparwdopodobniej tak, pewności nie mam czy zawsze, czy jakieś API nie będzie mieć innej implementacji, bo chyba nie jest to zachowanie ściśle określone.
Jakby mnie ktoś o ten konkretnie przykład pytał, to tak bym odpowiedział: "nie mam 100% pewności, nie wiem, zgłaszam wątpliwość do wyjaśnienia ;)".

Na sam koniec "druga fala timeoutów" do WebAPI i jeden kawałek kodu z najbardziej zagnieżdżonego setTimeout do Event Loop

    a++;
    console.log("1 Attempt: " + a);

A ponownie zwiększone o 1 i na konsoli: 1 Attempt: 12

TLDR;

@kacor11: wrzucił modelowy "film z przypisów".
Zasada jest: cały kod jest wykonywany, a setTimeout lecą na później do obsługi/wywołania przez API i kiedy przyjdzie ich czas lądują w kolejce do wykonania: każdy fragment kodu jako osobna paczka, po kolei paczka po paczce brana z event queue i wykonywana.

Gdy w takiej paczce będzie setTimeout to trafia on normalnie do API, czeka na swój czas, leci do event loop i stamtąd po dequeue jest wykonywany.

Zadanie/pytanie miało pokazać czy wiesz o czym mowa na wyżej wspomnianym filmie a nie o callback hell, Promise, async/await

BraVolt napisał(a):

później web API 2 kawałki kodu z 2 wywołań setTiemout po kolei do Event Loop

Kopiuj

  a++;

i

Kopiuj

  console.log("2 Attempt: " + a);

Właśnie dlaczego tak a nie na odwrót?

Z tego co rozumiem to web API może napełnić Event Loop w takiej kolejności:

   console.log("2 Attempt: " + a);

  a++;

@Karaczan:

Za słaby jestem, żeby powiedzieć na 100% tak a nie inaczej. jak wyżej, na rekrutacji powiedziałbym, że nie mam pewności co do kolejności. Najprawdopodobniej FIFO, ale jakby to miało być istotne, to tu leży temat do rozpoznania. IMHO lepiej wypadniesz mówiąc: tu nie wiem, mam wątpliwości do rozwiania (specyfikacja API), a nie na szybko: "tu moje rozwiązanie, następny temat proszę".
Nigdy nie będziesz wiedzieć wszystkiego, dlatego warto wiedzieć, gdzie możesz popełnić błąd.

BTW, po rekrutacji pozytyw?

Odpowiedzieli mi że wstrzymują się z rekrutowaniem kogokolwiek :(
Ale niedługo potem ponownie umieścili tą ofertę pracy na portalach.
Więc pewnie nie nie znaleźli nikogo wystarczająco dobrego wtedy.