Zacznijmy od historii słów kluczowych async/await. Zostały wprowadzone do EcmaScript w wersji 8 (rok 2017). Zgodnie z informacją podawaną przez stronę caniuse.com wszystkie liczące się przeglądarki mają te słowa zaimplementowane. A nawet jeśli okazałoby się, że wcześniejsza wersja przeglądarki tego nie wspiera, z pomocą przychodzi TypeScript, który identyczne słowa kluczowe udostępnia już od wersji 1.7 wydanej w 2015. Warto na marginesie odnotować, że async/await zostało jeszcze wcześniej dodane do języka C# i nie wydaje się przypadkiem, że ostatecznie trafiły do TypeScripta. A to dlatego, że jednym z projektantów tego języka jest niejaki Anders Hejlsberg, który jest również twórcą języka C#.

Tym oto sposobem dochodzimy do sedna sprawy. Dzięki await możemy pisać kod asynchroniczny w taki sposób, jakby wykonanie wyglądało na synchroniczne. Już wprowadzenie obietnic ograniczało callback hell, czyli wielokrotnie zagnieżdżone callbacki.

callbackHell1(function(result1) {
 callbackHell2(function(result2) {
  callbackHell3(function(result3) {
  //etc….
  });
 });
});

Poniżej ten sam przykład z użyciem obietnic.

callbackHell1().then(function(result1) {
 return callbackHell2();
}).then(function(result2) {
 return callbackHell3();
}).then(function(result3) {
 //etc…
});

Jak widać jest już znacznie lepiej, ale może być jeszcze lepiej. Zobaczmy, jak to będzie wyglądać, gdy użyjemy await.

const result1 = await callbackHell1();
const result2 = await callbackHell2();
const result3 = await callbackHell3();

No proszę, już lepiej chyba być nie może. Wszystko jest jasne i przejrzyste. Oczywiście należy pamiętać, że to wszystko jest tylko „syntaktycznym lukrem”, a pod spodem kod wykonuje się rzeczywiście asynchronicznie. Co najważniejsze słowa await możemy użyć wyłącznie w kontekście funkcji, która będzie oznaczona słowem kluczowym async.

async function asyncHeaven(){
 return await callbackHell1();
}

I jeszcze jedna ważna rzecz: te słowa kluczowe współpracują wyłącznie z obietnicami. A więc await możemy postawić przed wywołaniem, które zwraca Promise, a funkcja oznaczona przez async musi zwrócić również Promise.

A teraz coś na temat „obserwabli”. Gdy ponad rok temu zawodowo zetknąłem się z Angularem, i to od razu w wersji 5, a wraz z nim z biblioteką rxjs, pomyślałem że Observable to nowy lepszy Promise. Zwłaszcza, że Angular promuje te pierwsze w nowym kliencie http. Wydawało mi się wówczas naturalne, żeby również w projekcie, w którym jestem zaangażowany, forsować stosowanie Observable . Chociażby dlatego, aby w całym projekcie w spójny sposób obsługiwać asynchroniczny kod. Z większym lub mniejszym powodzeniem się to udawało. Ale zacząłem dostrzegać też pewne niedogodności z tym związane.

Podstawową różnicą w działaniu Observable jest to, że jeżeli nie wywołamy na nim metody subscribe, wówczas asynchroniczna metoda się nie wykona. Przykład to np. http.get:

import { HttpClient } from '@angular/common/http';
@Injectable()
export class TestowyService {
 constructor(private http: HttpClient) {}
 public getConfig(): Observable < any > {
  return this.http.get(‘jakiśurl’);
 }
}

Jeżeli w powyższym przykładzie nie zasubskrybujemy wyniku metody, wówczas do serwera nie pójdzie żądanie GET. Może to czasami być zaletą, ale jeżeli do tej pory ktoś korzystał z obietnic, to może się zdziwić, bo nie mamy obowiązku wywoływać then.

Druga sprawa to fakt, że te obiekty nie są częścią języka, w związku z tym wprost nie są wspierane przez async/await. Aby to zrobić, musimy najpierw przekonwertować do obietnicy za pomocą metody toPromise.

Nie jest to wszystko szczególnie uciążliwe, ale pokazuje, że nie ma sensu na siłę korzystać z „obserwabli” jeżeli nie jest to koniecznie. Są oczywiście sytuacje, gdy obietnice nie znajdują zastosowania, a obiekty z biblioteki rxjs są wówczas niezastąpione, o czym kilka razy pisałem.