Observable – rxjs 5

[type-of-web-komentarze[bot]]

Observable – rxjs 5

To nie będzie wpis na temat teorii reaktywnego programowania funkcyjnego. Nie jest to też wyciąg z dokumentacji rxjs. Ten wpis jest krótkim praktycznym wprowadzeniem do Obserwabli na przykładzie. Zaczynajmy!

https://typeofweb.com/observable-rxjs

[type-of-web-komentarze[bot]]

Gravatar	Imię	Adres	Data
	Comandeer	https://www.comandeer.pl/	2017-05-20 07:44

Fajne, ale… Może jestem jakiś dziwny, niemniej za dużo magii czuję pod spodem i jestem nieufny. Pod względem używania tego jest całkiem przyjemnie, niemniej zawsze mnie drażni jak coś jest za bardzo lib-dependent. Tutaj wykorzystujesz masę funkcji typowych dla Rx.js, które z oczywistych powodów nigdy nie trafią do standardu ES.

Inna rzecz, że obecna propozycja nie uwzględnia nawet metod filter i map. I to jest bez sensu, bo (teraz wyjdzie jak bardzo lamię :D) przecież Observable to taka "żywa" tablica z danymi i filtrowanie to podstawa…

 
 

Komentarz zaimportowany z WordPressa

[type-of-web-komentarze[bot]]

Gravatar	Imię	Adres	Data
	Comandeer	https://www.comandeer.pl/	2017-05-20 10:29

Jeszcze co do Haskella: prawdę mówiąc nigdy mu się bliżej nie przyglądałem – mimo wszystko bardziej ciągnie mnie do języków OOP. Jeśli jest tak, jak w Haskellu, to fajnie. Nie zmienia to jednak faktu, że na gruncie JS wciąż jest to dość egzotyczna technika.

Co do implementacji zgodnej, ale rozszerzonej: owszem, dobrze, że jest zgodna. Niemniej prawdziwą przenośność kodu zapewniłoby dopiero ograniczenie się do tego, co jest zdefiniowane w standardzie. Inaczej mimo wszystko robimy sobie lock-in technologiczny. Największy ból polega na tym, że obecna propozycja Observable i tak jest nieużywalna, więc lock-in tylko się pogłębia, bo i tak wszyscy użyją Rx.js albo ekwiwalenta tej biblioteki. I IMO jest to pewien problem (w taki sam sposób Angular i React po prostu zniszczyły Web Components).

Tendencja jest dobra, bo chcemy ukrywać trudną obsługę asynchroniczności pod warstwą przyjemnej abstrakcji.

Tylko w którą stronę to idzie? Mamy callbacki, Promise, generatory, async/await, WHATWG definiuje obecnie streamy i w końcu mamy też Observable… Robi się dość tłoczno ;)

 
 

Komentarz zaimportowany z WordPressa

[typeofweb]

Gravatar	Imię	Adres	Data
	Michał z typeofweb.com	https://typeofweb.com	2017-05-21 15:57

Chwila chwila :) Generatory są synchroniczne, przynajmniej na razie, więc rozwiązują inny problem.
Async/await to tylko cukier na Promise, nic nowego, tylko składnia przyjemna. No i tą metodą obsłużysz tylko pojedyncze zdarzenia, Promise sie rozwiązuje raz i koniec.
Callback i Observable mogą służyć do obsługi wielokrotnych asynchronicznych zdarzeń, ale trzeba przyznać, że callbacki są mniej czytelne i ekspresywne niż Observable :)

 
 

Komentarz zaimportowany z WordPressa

[type-of-web-komentarze[bot]]

Gravatar	Imię	Adres	Data
	Comandeer	https://www.comandeer.pl/	2017-05-21 16:04

Generatory są synchroniczne, przynajmniej na razie, więc rozwiązują inny problem.

Tzn tak, teoretycznie rozwiązują inny problem, ale przecież to właśnie one były inspiracją do stworzenia składni async/await → http://webroad.pl/javascript/746-synchroniczna-asynchronicznosc

Tak, async/await to tylko przyjemna składnia, ale mimo wszystko większość kodu asynchronicznego jest w moim odczuciu jednorazowa, więc tego typu składnia stanie się popularna.

Tak, callbacki i observable nadają się do powtarzalnej asynchroniczności, ale w dużej liczbie projektów powtarzalna asynchroniczność sprowadza się do obsługi zdarzeń DOM-owych, co niekoniecznie wymaga observables (zwłaszcza do prostej obsługi klików).

Mówiąc "tłoczno" miałem na myśli, że mamy wiele różnych rzeczy, które niby się pokrywają, równocześnie mając subtelnie inne use case'y. To IMO wprowadza, przynajmniej na początku, niepotrzebne zamieszanie.

 
 

Komentarz zaimportowany z WordPressa

[typeofweb]

Gravatar	Imię	Adres	Data
	Michał z typeofweb.com	https://typeofweb.com	2017-05-23 00:34

Jeśli masz po prostu na myśli to, że nie ma sensu użyć rxjs jeśli się go nie potrzebuje to tak, jak najbardziej. Jest to prawdziwe odnośnie każdej biblioteki :)

Jednak praca (zabawa?), z rxjs to też pewnego rodzaju gimnastyka umysłu (podobnie jak pisane w Haskellu), dlatego też polecam każdemu spróbować :) Zupełnie inaczej się potem patrzy na świat.

 
 

Komentarz zaimportowany z WordPressa

[type-of-web-komentarze[bot]]

Gravatar	Imię	Adres	Data
	Comandeer	https://www.comandeer.pl/	2017-05-23 09:15

Jeśli masz po prostu na myśli to, że nie ma sensu użyć rxjs jeśli się go nie potrzebuje to tak, jak najbardziej.

To też. Bardziej mnie zastanawia, po co do standardu ES do każdej wersji dokładać "nowy, lepszy sposób na async!!!!!" ;) Jak teraz wejdą Observables, to boję się, co wymyślą za rok.

Jednak praca (zabawa?), z rxjs to też pewnego rodzaju gimnastyka umysłu

Co za czasy nastały… Kiedyś się kod pisało dla przyjemności, teraz się trzeba gimnastykować! :P

Ale tak, skrobnę se coś z tym, bo wygląda ciekawie.

 
 

Komentarz zaimportowany z WordPressa