Synchroniczna asynchroniczność

Jest pewna rzecz w JavaScript, którą wszyscy kochamy: asynchroniczność. Jest też pewna rzecz w JS, którą wszyscy nienawidzimy: asynchroniczność. Każdy, kto choć raz miał większy kontakt z tym dziwacznym językiem, wie czym jest budząca postrach asynchroniczność. To zmora wszystkich AJAX-owych wyjadaczy i ich młodszych kolegów, hackujących w node.js.

Ale o co chodzi?

Jak niektórym wiadomo, JS jest językiem jednowątkowym. W uproszczeniu mówiąc: może wykonywać tylko jedną rzecz naraz. Oczywiście zrodziło to szereg konsekwencji i zmusiło co tęższe głowy do szukania rozwiązań i obejść tego problemu. O jakich konsekwencjach mówimy? Wyobraźmy sobie już tutaj wspomniane żądanie AJAX-owe. Wysyła ono zapytanie o dane do konkretnej strony internetowej. Jak wiadomo, to trwa – w zależności od wielu różnych czynników (prędkość połączenia, wydajność i obciążenie serwera docelowego itd.) – od kilku sekund do nawet kilku minut. Gdyby JS był zupełnie „normalnym” językiem programowania, takie zapytanie oznaczałoby zawieszenie całego programu, który czekałby na odpowiedź. Zero odpowiedzi na kliknięcia przycisku („Człowieku, nie widzisz, że ja tu czekam?!”), zero padającego śniegu („CZEKAM! DAJ MI SPOKÓJ!”), zero… I w tym miejscu wkracza właśnie na scenę asynchroniczność: a co gdyby takie żądanie wykonywało się w mitycznym tle a cała reszta strony była wciąż w pełni funkcjonalna? Oczywiście od razu kupiono ten pomysł. I tu pojawił się problem.

Mityczne działanie w tle pociąga za sobą jedną, niezwykle ważną konsekwencję, która często pozostaje niezrozumiała dla nowicjuszy i ludzi dotąd korzystających z innych języków programowania. Otóż któż z nas nie próbował zrobić czegoś takiego:

Jakaż wielka była nasza frustracja, gdy uzmysławialiśmy sobie, że to po prostu nie działa… Jak dla mnie był to największy moment oświecenia w moim obcowaniu z JS-em: zrozumienie, że funkcje asynchroniczne nie zwracają wartości. Rozwiązując problem zawieszania się programu, równocześnie natknęliśmy się na kolejny, równie ważny.

Callbacki

Najprostszym i najczęściej stosowanym rozwiązaniem (choć totalnie nielogicznym dla newbies) jest zastosowanie tzw. callbacków. Nasza funkcja asynchroniczna radośnie wykonuje się w tle i gdy wreszcie uda się jej pobrać pewne dane, przekazuje je do funkcji, zadeklarowanej przez nas, która nam jeszcze radośniej owe dane przerobi. Wygląda to o wiele straszniej niźli zwykłe  var result, choć wciąż jest w miarę jasne:

Voilà! Dostaliśmy się do tego, co chcieliśmy. Jest tylko jeden problem: nie istnieje sensowny sposób przekazania pobranych danych do reszty skryptu – jedyne miejsce kontaktu z nimi to wnętrze callbacku. Niekoniecznie jest to wada (hej, mamy natywną enkapsulację ;)), lecz warto o tym pamiętać.

Jak widać, callbacki można łatwo sobie przyswoić i są nawet przyjemne, prawda? Błąd! To, że nie istnieje sensowny sposób na wyjęcie potrzebnych nam danych poza callback, oznacza, że wszystkie operacje od nich zależne należy wykonać w jego wnętrzu. I choć zaczyna się niewinnie, bardzo łatwo skończyć z kodem w postaci:

Zaczyna się robić bardzo nieprzyjemnie, prawda? W przypadku bardziej skomplikowanych aplikacji grzęźniemy w callbackach powsadzanych w callbacki, które z kolei są odpalane w callbackach innych callbacków. Po kilku godzinach pracy z takim kodem słowo „callback” staje się uosobieniem wszelkich koszmarów a kod nimi usiany wygląda jak pismo szatana. Nic zatem dziwnego, że postanowiono poszukać sensowniejszego rozwiązania problemu asynchroniczności.

Model zdarzeniowy

Jeśli ktoś wie, co to DOM (jeśli wiesz, to pewnie na dźwięk tej nazwy również jeżą Ci się włosy na głowie ;)) albo przynajmniej posługiwał się kiedyś jQuery, zna też model zdarzeniowy. To dzięki niemu przeglądarka jest w stanie reagować na kliknięcia przycisków, pacnięcia headera, wciśnięcia klawiszy oraz wszystkie te dziwne rzeczy, które user z nią próbuje zrobić. Zasada tutaj jest prosta: mamy pewien obiekt (np. przycisk), któremu może się coś stać (np. zostanie zmolestowany kliknięciem). W chwili, gdy to coś się stanie, nasz obiekt po prostu o tym informuje. I w sumie tyle. W teorii brzmi to prosto (aż za prosto), w praktyce też nie jest szczególnie skomplikowane. Posłużę się tutaj prostym przykładem z jQuery:

Co bardziej wyczuleni zauważą, że w sumie tutaj też mamy pewien rodzaj callbacku: w końcu po dostaniu informacji od przycisku, że ktoś go kliknął, wywołujemy funkcję. Gdzie zatem jakaś zmiana? A otóż w tym, że w przypadku modelu zdarzeniowego nie jesteśmy uzależnieni od jednego, monolitycznego callbacku. Obsługę danego zdarzenia możemy rozrzucić po wielu fragmentach naszego kodu (oczywiście sensownych) i podzielić na mniejsze, bardziej wyspecjalizowane fragmenty:

Takie rozwiązanie jest o wiele elastyczniejsze od normalnego callbacku. Co więcej, praktycznie każdy natywny moduł node.js wspiera ten model. To samo dotyczy de facto każdego API dostępnego w przeglądarce (obiekt  XMLHttpRequest, odpowiedzialny za AJAX-a, również go wspiera). Model zdarzeniowy jest standardowym sposobem reagowania na wszelkie zmiany i interakcje z użytkownikiem. Pozwala wielu niezależnym od siebie częściom programu reagować ze sobą (np. moduł B może nasłuchiwać czy przypadkiem moduł A nie rzuca błędu), co pozwoliło Zakasowi na stworzenie skalowalnej architektury aplikacji w JS.

Promises (Futures)

Choć model zdarzeniowy jest bardzo potężny, nie zawsze się go wykorzystuje. Wyobraźmy sobie prostą funkcję do pobierania danych z bazy danych. Owszem, może ona emitować zdarzenie  completed w chwili pobrania danych i można tego zdarzenia nasłuchiwać, ale wydaje się to pewnym przerostem formy nad treścią. Co więcej, w niektórych przypadkach potrzebujemy całości obsługi w jednym miejscu. Nie chcemy równocześnie babrać się z surowymi callbackami, bo są po prostu brzydkie. Na pomoc przychodzą nam promises (zwane też czasami futures).

Czym jest ten dziwny mechanizm, który zdobył tak wielką popularność i serca programistów JS na całym świecie? Powstał on jako jedna z propozycji tzw. CommonJS APIs (ma nawet swojąspecyfikację). Pomysł okazał się na tyle dobry a zarazem prosty i przyjemny, że wkrótce opanuje całe DOM API (co w gruncie rzeczy jest powodem do świętowania :D). Całość w gruncie rzeczy opiera się na jednej metodzie –  then, służącej do łączenia w łańcuchy poszczególnych funkcji asynchronicznych. Pozwala to pisać o wiele przejrzystszy kod niźli w przypadku zastosowania surowych callbacków. Załóżmy, że nasza metoda  AJAX.get korzysta z promises – jej najprostsze wywołanie zatem wyglądałoby następująco:

Jak widać, nie przekazujemy już do  AJAX.get callbacku – pojawia się natomiast  then, które… Tak, bierze dwa callbacki ;) Spokojnie, ma to swój sens. Pierwszy z nich odpala się jedynie w przypadku, gdy wszystko poszło dobrze i otrzymaliśmy potrzebne zdanie. Drugi służy do obsługi błędów. Co prawda na tak prostym przykładzie nie widać zbyt dobrze przewagi promises nad normalnymi callbackami, jednak wystarczy przyjrzeć się naszemu nieprzyjemnemu przykładowi z callbackami, by dostrzec rzeczywistą przewagę obiecanek:

Żegnajcie, okropne poziomy zagłębień i tryliony następujących po sobie nawiasów! Witajcie, pięknie i czytelne promises! Wygląda pięknie, prawda? Oczywiście coś za coś ;) Jeśli już raz wejdzie się w promises, to de facto cały kod powinien ich używać (inaczej nie będzie można utworzyć łańcuszka z  then). Mimo wszystko nie ma raczej konkretnych przeciwwskazań do stosowania promises (chyba, że musimy mieć maksymalną wydajność – wówczas lepiej rozglądnąć się za innym rozwiązaniem) a obecnie są najczytelniejszym mechanizmem obsługi asynchronicznego kodu w przeglądarce.

Co się dzieje za kulisami? Wyobraźmy sobie prościutką funkcję asynchroniczną – jej jedynym zadaniem jest… bycie asynchroniczną i zwrócenie losowo albo poprawnego wyniku, albo błędu. Wymusić asynchroniczność jest bardzo łatwo – wystarczy zastosować timer ( setTimeout/ setInterval; w przyszłości prawdopodobnie będzie można także skorzystać z genialnego  <a href="http://www.nczonline.net/blog/2013/07/09/the-case-for-setimmediate/">setImmediate</a>, prawda Firefox i Chrome? W node.js jest już dostępne od wersji 0.9). Natomiast co do losowania wyniku można posłużyć się np. ładną funkcją  rand. W ostateczności otrzymujemy coś takiego:

Jak nie trudno się domyślić, po 1 sekundzie zobaczymy albo napis 'Działa’, albo ładny błąd. Teraz zastanówmy się jak zrobić z tego obiecankę. Najnowsze przeglądarki udostępniają globalną funkcję  Promise, której oczywiście nie należy jeszcze używać (jest tzw. eksperymentalną funkcjonalnością i trzeba grzebać w ustawieniach, żeby się w ogóle do niej dobrać). Na szczęście istnieją setki implementacji promises, wśród których jest także używana przeze mnie, when.js. Również jQuery udostępnia niby-promise ( jQuery.Deferred), jednak nie jest to do końca zgodna ze standardem implementacja. W tym artykule użyjemy when.js.

W przypadku when.js, promise jest tak naprawdę częścią większego obiektu, zwracanego przez metodę  when.defer. Ma on 2 metody:  resolve (zwracającą wartość i uruchamiającą 1. callback w  then) oraz  reject (rzucającą błędem i uruchamiającą 2. callback w  then) oraz 1 własność:  promise (tak, to nasz skubaniec z  then). Po zmianach nasza funkcja może wyglądać następująco:

Jak widać, zmiany nie są szczególnie drastyczne – dają się znieść. Dzięki nim dostajemy w pełni działającą obiecankę, która pozwala nam w znaczny sposób uczytelnić nasz kod.

Obsługa błędów

Dla programistów, zwłaszcza przychodzących do JS z innych języków, najbardziej naturalną formą obsługi błędów jest mechanizm wyjątków. W JS jest również obecny i działa tak, jakbyśmy tego oczekiwali. Ale nie do końca…

Powyższy kod, niezgodnie z intuicją, wyrzuci nam błąd:

Uncaught Error: HA!

„Konsola”

Jakkolwiek byśmy nie próbowali, obsługa wyjątków w przypadku funkcji asynchronicznych nie zadziała. Trzeba znaleźć inne sposoby obsługi błędów. Jeden już znamy – jest nim drugi callback w then. Ale co choćby w przypadku zwykłych, surowych callbacków? Otóż w ich przypadku powstał niepisany standard (spotykany zwłaszcza w czasie pracy z node.js): 1. parametr callbacku oznacza błąd (lub  null/ undefined jeśli błąd nie wystąpił), natomiast 2. parametr to otrzymane dane. Tutaj warto także od razu zaznaczyć, że drugim niepisanym standardem jest umiejscawianie callbacku jako ostatniego parametru. Zobaczmy to na przykładzie pobierania danych z pliku:

W node.js bardzo popularnym rozwiązaniem jest także wywołanie zdarzenia  error (de facto większość natywnych modułów w node.js zawiera metody, które takie zdarzenie emitują):

W przeglądarce również wiele różnych API zwraca błędy w ten sposób (słynne  image.onerror). Chyba najuniwersalniejszym użyciem tego w tym środowisku jest  window.onerror, łapiące większość błędów, które zdarzają się na stronie. Korzysta z tego m.in. Errorception. Niemniej, jakkolwiek by na sprawę nie patrzeć, taki sposób obsługi błędów nie jest aż tak intuicyjny, jak stare, sprawdzone wyjątki.

Synchroniczna asynchroniczność?

Największą bolączką asynchronicznośći jest zaburzenie kolejności czytania kodu. W JS nigdy nie możemy mieć pewności, że wszystko wykonuje się w porządku, w którym jest wypisane na ekranie. Stąd tak usilna potrzeba rozwiązań takich jak promises – pozwalają one choć trochę uporządkować callbackowe piekło. Jednak wciąż nie są tak wygodne jak zwykły, synchroniczny kod. Czy zatem jesteśmy skazani na takie rozwiązania pośrednie? I tak, i nie.

Promises były wielkim skokiem naprzód, lecz programiści wciąż szukali coraz dziwniejszych sposobów, żeby kod asynchroniczny przypominał synchroniczny. Ich poszukiwania doprowadziły do powstania node-fibers. Jak sama nazwa wskazuje, jest to rozwiązanie napisane z myślą o node.js. Wykorzystuje ono potęgę… C++, dodając kilka ciekawostek do silniczka V8 (silnik JS, wyjęty z Chromium, na którym zbudowano całe node.js). Jest to rozwiązanie bardzo potężne, ale równocześnie zbyt inwazyjne i nigdy nie znajdzie się w przeglądarkach.

Na ratunek przychodzi nam jednak ECMAScript 6 a dokładniej jedna z jego części, zwąca się enigmatycznie generatorami. I choć specyfikacja jest po prostu całkowicie niestrawna, generatory można bardzo prosto ogarnąć. Zacznijmy od przykładu:

W sumie widzimy, że generator to tak naprawdę funkcja, choć jakoś tak dziwnie zadeklarowana (pojawia się  * przy słówku kluczowym  function) oraz nowe słówko kluczowe  yield (można w dużym uproszczeniu potraktować je jako generatorowy odpowiednik  return). Widzimy też inifinite loop ( while(true)), co powinno od razu zapalić czerwoną lampkę w głowach wszystkich programistów (wszak nie ma nigdzie żadnego  break) – w teorii po odpaleniu tej funkcji pętla powinna zablokować cały program i lecieć tak długo, aż nie skończy się nam pamięć. Tak się jednak nie dzieje. Dlaczego? Przypatrzmy się jak „tradycyjnie” można by zapisać powyższy generator:

Jak widać, stworzenie prostego pseudogeneratora jest bardzo proste (jest tak proste, że TC39 – grupa zajmująca się ES6 – stwierdziła wręcz, że nie ma potrzeby wprowadzać mechanizmu rozróżniającego generator od zwykłej funkcji). Po głębszej analizie i porównaniu obydwóch przykładów można dojść do wniosku, że  yield w automagiczny sposób sprawia, że działanie generatora jest przerywane aż do czasu kolejnego wywołania  iterator.next, po czym zaczyna wykonywać jego kod od kolejnej po  yield komendzie (w naszym wypadku to kolejne  yield z powodu pętli ;)) – po prostu „skacze” między kolejnymi wystąpieniami  yield. „I co z tego?” – zapyta się co bardziej rozgarnięty czytelnik. A to, że można przerwać wykonywanie generatora na funkcji asynchronicznej, pozwolić się jej wykonać, po czym wrócić do generatora! Brzmi obiecująco? Oczywiście od razu pojawi się problem w jaki sposób wykorzystać ten mechanizm, żeby funkcja asynchroniczna powróciła do generatora (czyli wywołała  iterator.next) a równocześnie przekazała mu wartość (czyli wywołała  iterator.next z parametrem ;)). Okazuje się, że i tutaj niezbędny będzie callback. Jednak całość kodu staje się o wiele przyjemniejsza (przykład z node.js):

Można zakrzyknąć: nareszcie! Mamy asynchroniczny kod, w którym działa  var – jedynymi niedogodnościami są słówko  yield oraz potrzeba przekazywania callbacku. Choć pierwszej zlikwidować się nie da, druga jest możliwa do usunięcia (o czym później). Widać zatem, że możliwe jest stworzenie kodu asynchronicznego, który wygląda de facto jak synchroniczny (i tak też się zachowuje, wykonując się od góry do samego dołu). Oczywiście tutaj też istnieją pewne niemożliwe do przeskoczenia ograniczenia asynchroniczności (wciąż nie da się zwrócić normalnie wartości z wnętrza generatora do reszty kodu – choć w tym wypadku raczej nikt nie ma ochoty wychodzić poza generator, jeśli to nie jest absolutnie konieczne ;)), niemniej kod staje się maksymalnie czytelny, bez porzucania korzyści płynących z asynchroniczności. A co z obsługą błędów? Dobra wiadomość jest taka, że wyjątki wewnątrz generatora w końcu działają tak, jak się tego spodziewamy! To wszystko dzięki metodzie  iterator.throw:

Jak widać dodaliśmy tylko jedną linijkę do naszego callbacka i już możemy wewnątrz generatora korzystać z dobrodziejstw wyjątków.

Trzeba przyznać, że kod napisany przy użyciu generatorów wygląda po prostu ładnie – nawet promises nie mogą się z nim równać. Ale zanim polecisz przepisywać swój kod na generatory, czas na kubeł zimnej wody: generatory to ficzer z ES6, które oficjalnie nie jest zaimplementowane w żadnej przeglądarce. Zarówno w Firefoxie, jak i Chrome, żeby skorzystać z nich, należy grzebać w ustawieniach. W przypadku node.js również trzeba wykonać dodatkowy kroki, czyli zainstalowanie wersji >=11.6.x i uruchomienie node z parametrem  --harmony. Nie zraża to jednak entuzjastów do eksperymentowania z tym niezwykle użytecznym mechanizmem.

W Sieci pojawiło się wiele bibliotek, które służą za wrapper dla generatorów. Ich jedynym zadaniem jest dbanie o to, żeby wywoływać za nas  iterator.next (lub rzucać błędy przez  iterator.throw) i dostarczać odpowiednich callbacków. Takimi biblioteki są m.in. waitfor (która potrzebuje po prostu  yield [funkcja,parametry] a sama zajmuje się resztą) czy też task.js. Zobaczmy jak ładnie może to wyglądać:

Generatory + promises – brzmi jeszcze lepiej, prawda? Można zapomnieć w zupełności o callbackach – po prostu wywołujemy funkcję a cała magia dzieje się za kulisami. To akurat przykład zaczerpnięty ze strony task.js. Jak widać, cały kod jest umieszczony wewnątrz funkcji  spawn a jedynym naszym zadaniem jest umieszczenie  yield w odpowiednich miejscach. Czyż nie jest to piękne?

Jak widać generatory zdają się być jak dotąd najdoskonalszym rozwiązaniem problemu asynchroniczności. Kod stworzony dzięki nim jest czysty, przejrzysty i o wiele krótszy. Jedynymi prawdziwymi zmartwieniami w sprawie generatorów są obecnie małe wsparcie i wydajność (co oczywiście z czasem powinno się zmienić na lepsze). Natomiast łatwość użycia już podziałała na środowisko JS-owców, którzy coraz agresywniej z tym eksperymentują (nie muszę chyba zaznaczać, że mnie również generatory kupiły od razu ;)). Zostaje tylko czekać i… samemu eksperymentować. Tym bardziej, że stworzenie własnego wrappera na generatory wcale nie jest trudne i można to zrobić w zasadzie w ciągu kilkunastu minut. Co też zrobimy. Ale nie dziś ;)

Tagi: asynchroniczność • JavaScript