Czym jest programowanie reaktywne ?

Czy ktoś może w prosty sposób wyjaśnić czym jest programowanie reaktywne w Reacie ?

Masz eventy, które są emitowane przez emitterów i nasłuchiwane przez subscriberów.

Ale to react sam w sobie ma juz wbudowanych te subscribery ? Mówie o czystym Reacie bez żadnych dodatków.

sajek587 napisał(a):

Mówie o czystym Reacie bez żadnych dodatków.

React sam w sobie jest dodatkiem do JavaScriptu i ma takie same możliwości jak on :)

Programowanie reaktywne to paradygmat, idea i zbiór zasad definiujących wytwarzanie oprogramowanie w ten sposób. React jest biblioteką JS. Jakieś elementy programowania reaktywnego pewnie implementuje, ale jeśli chodzi o programowanie reaktywne, to powinieneś zainteresować się RxJS.

Czyli React sam w sobie posiada paradygmat programowania reaktywnego czy nie ? Często się spotyka ze stwierdzeniem, że React posiada cechy programowania reaktywnego.

sajek587 napisał(a):

Czyli React sam w sobie posiada paradygmat programowania reaktywnego czy nie ?

Żadna biblioteka ani język programowania nie może mieć/posiadać paradygmatu. Paradygmat to nie są żadne dodatkowe funkcje lub możliwości; tylko zbiór obostrzeń, blokad, zakazów. Biblioteka lub język może co najwyżej wpisywać się w pewne kryteria, i w ten sposób wpasować się w dany paradygmat, lub nie.

Programowanie reaktywne to podzbiór programowania deklaratywnego, które też ma swoje obostrzenia i zakazy.

Samo programowanie reaktywne polega na tym, że tworząc nowe wartości np wiek = aktualnyRok - rokUrodzenia, odczytanie zmiennej wiek da jedną wartość, ale jeśli wartości aktualnyRok lub rokUrodzenia się zmienią, to odczyt wiek również będzie inny - czyli inaczej niż w programowaniu imperatywnym, gdzie raz ustalona wartość się nie zmienia i wymagane byłoby ponowne przypisanie.

Jeśli ktoś sobie wyobrazi że komponenty w React'ie to zmienne, a przypisane im propy to wartości, to można powiedzieć że w sumie tak - model widoku Reacta wpisuje się w programowanie reaktywne - bo faktycznie zmiana propa w jednym komponencie jest widoczna jako zmiana w każdym kolejnym.

Ale jeśli dodamy do tego hooki, state, effecty, eventy, globalny stan, contexty, calle do backendu, wszelkiego rodzaju debouce'e i inne takie, to trzeba by się zastanowić głębiej czy nie łamie to jakiejś zasady programowania reaktywnego.

sajek587 napisał(a):

Czyli React sam w sobie posiada paradygmat programowania reaktywnego czy nie ? Często się spotyka ze stwierdzeniem, że React posiada cechy programowania reaktywnego.

Moim zdaniem tak - React jest reaktywny, bo komponenty same wiedzą, kiedy się wyrenderować z powrotem - jak się zmieni stan, to komponent Reacta sam się wyrenderuje z powrotem.

Ale jeśli chcesz ostatecznej odpowiedzi, to cóż - programowanie reaktywne to taki slogan, który jest używany w JS dość intuicyjnie i mało kto wnika dokładnie, co to oznacza (więc być może sam się mylę w tym momencie), więc trzeba byłoby sięgnąć do jakichś papierów naukowych.

A czasem wręcz dochodzi do absurdów, gdzie autorzy bibliotek do reaktywności dodają słówko "functional" i twierdzą, że robią coś "functional reactive" i tutaj muszą być prostowani, że piszą głupoty ("functional reactive programming"(FRP) to specyficzny rodzaj reaktywności, a nie po prostu reaktywność + funkcyjność. Nie będę już tutaj wnikał, bo nie chcę czegoś pokręcić, polecam poczytać: https://en.wikipedia.org/wiki/Functional_reactive_programming oraz http://conal.net/papers/icfp97/ )

@LukeJL: Zgadzam się ze wszystkim co opisałeś w poście wyżej, ale tak się zastanawiam, jak React ogarnia zmieniające się atrybuty obiektów i tablic przekazanych przez referencję.

const objectRef = {nested: {value: 2}};

const component = <Comp obj={objectRef}/>; // to się chyba nie odświeży, nie?

objectRef.nested.value = 3;

Wiem, że w dokumentacji jest napisane żeby takich nie przekazywać, no ale still.

Na dobrą sprawę, nawet bez referencji to trochę nie pasuje, bo przecież możemy zrobić:

const value = 2;
const component = <Comp value={value}/>; // to się nie odświeży
value = 3;

A zgodnie z paradygmatem reaktywnym powinno. No chyba że uznamy że "zmienne" nie są częścią Reacta, a jedynie komponenty - to wtedy tak.

Programowanie reaktywne: coś się stało z danymi -> odpalana jest akcja, która została zarejestrowana dla tego typu zmiany.
Programowanie imperatywne: czekasz na zakończenie akcji, która coś robi z danymi -> idziesz do następnej akcji.

Samo programowanie reaktywne to troche termin z d**y, bo jak widać bardzo łatwo zaimplementować normalne programowanie imperatywne przy pomocy reaktywnego przez co samo pojęcie się rozmywa. To co wyróżnia programowanie reaktywne od imperatywnego to fakt, że same "reakcje" pod spodem używają czegoś bardziej skomplikowanego niż idź do następnej akcji. W przypadku NodeJS jest to event loop, który pozwala na użycie asynchronicznego io dzięki czemu jednowątkowy program może na raz obsługiwać wiele operacji io. W przypadku Reacta jest to uproszczone połączenia stanu z widokiem. Zamiast sprawdzać w pętli po kolei czy dana wartość się zmieniła (a jak tak to coś narysuj) to opisujemy od jakich danych dany komponent zależy a biblioteka wie co trzeba przerysować w optymalny sposób.

slsy napisał(a):

Programowanie reaktywne: coś się stało z danymi -> odpalana jest akcja, która została zarejestrowana dla tego typu zmiany.
Programowanie imperatywne: czekasz na zakończenie akcji, która coś robi z danymi -> idziesz do następnej akcji.

Samo programowanie reaktywne to troche termin z d**y, bo jak widać bardzo łatwo zaimplementować normalne programowanie imperatywne przy pomocy reaktywnego przez co samo pojęcie się rozmywa. To co wyróżnia programowanie reaktywne od imperatywnego to fakt, że same "reakcje" pod spodem używają czegoś bardziej skomplikowanego niż idź do następnej akcji. W przypadku NodeJS jest to event loop, który pozwala na użycie asynchronicznego io dzięki czemu jednowątkowy program może na raz obsługiwać wiele operacji io. W przypadku Reacta jest to uproszczone połączenia stanu z widokiem. Zamiast sprawdzać w pętli po kolei czy dana wartość się zmieniła (a jak tak to coś narysuj) to opisujemy od jakich danych dany komponent zależy a biblioteka wie co trzeba przerysować w optymalny sposób.

No trochę za bardzo popłynąłeś bo w programowaniu reaktywnym, nie ma czegoś takiego jak akcja. To jest deklaratywny paradygmat.

slsy napisał(a):

Samo programowanie reaktywne to troche termin z d**y, bo jak widać bardzo łatwo zaimplementować normalne programowanie imperatywne przy pomocy reaktywnego przez co samo pojęcie się rozmywa.

No właśnie wcale nie tak łatwo, bo musiałbyś specjalnie skopiować i zapisać stan, co jest sprzeczne z programowaniem reaktywnym. Jeśli możesz coś takiego łatwo zrobić, to to byłby argument że jednak to w czym piszesz nie jest reaktywne.

A nie chodzi po prostu o odwrócenie sterowania zachowaniem (nie mylić z IoC)?
Czyli imperatywnie mamy gdzies kod:

dane = pobierzDane()
labelka.tekst = dane

Czyli mamy głupią labelkę, której zachowanie jest sterowane zewnętrznie.

Reaktywnie mamy ten kod rozbity na 2 części

dane = pobierzDane()

i gdzieś tam w labelce ustawione

obserwujCzyDaneSięZmieniłyIAktualizujSwojąZawartość()

Czyli to labelka wie, że ma patrzeć sobie na jakiś kawałek modelu i w razie jego zmiany odpowiednio się zachować, Część pobierająca dane, nie musi wiedzieć co z nimi zrobić, bo ta wiedza tkwi w konsumentach.

React jakoś tam wspiera takie podejście, bo o ile pamiętam z prezentacji :) można tam komponentom wskazać co mają obserwować i jak reagować na zmiany tego w tych obserwowanych strukturach.

Oczywiście takie zachowanie nie musi być ograniczone do elementów widoku.

@piotrpo: Takie pojęcie jak "labelka sobie obserwuje czy ma się zmienić", to jest jedna z możliwych implementacji środowiska uruchomieniowego kodu napisanego w takim paradygmacie; ale implementacja całkowicie ukryta dla kodu napisanego w nim - więc to może być "obserwowanie", pollowanie, pushing, eventy, jakąkolwiek implementacje chcesz.

W programowaniu reaktywnym, w skrócie chodzi o to że:

name = "Mark"
surname = "Twain"
fullname = name + " " + surname

name = "John"
fullname; // "John Twain"

A to jak to pod spodem jest ogarnięte, to jest szczegół implementacyjny. Z punktu widzenia takiego języka nie jesteś w stanie ogarnąć czy to jest obserwowanie, polling, eventy czy cokolwiek bo po prostu język w którym piszesz działa tak że aktualizacja zmiennych i wartości zmienia też swoje pochodne.