Chciałem zapytać jakie przykładowe wymagania musiałby spełniać projekt, aby w rzeczywistości był sens wchodzić w reaktywne programowanie.
Nigdy nie programowałem w oparciu o ten paradygmat. Póki co widzę, że abstrakcja strumienia zachęca, do programowania funkcyjnego pozbawionego efektów ubocznych więc z użyciem strumieni raczej trudniej jest pisać kod, który coś przetwarza i na podstawie danych w strumieniu dociąga jeszcze dodatkowe dane z sieci.
Strumienie skoro buferują to mają stan (mogą buforować treść) i przy użyciu operatorów zarządzać nią i momentem emisji. Najpotężniejsza cecha sturmieni jaką widzę, to fakt, że można je łączyć z innymi strumieniami, co w przypadku zdarzeń z wielu źródeł daje podstawę do synchronizacji danych na różne sposoby.
Przykłady jakie jestem w stanie sobie wyobrazić to:
- czekanie na dane z kilku źródeł aż wszystkie dostaniemy wszystkie dane o zadanym kryterium, co umożliwia synchronizację zbliżoną do tego jak mamy napisy w filmach
- konkurencja z czasem czyli czekamy na dane, ale obok mamy drugi strumień przez który wyjedzie ze zdarzeniem jak nastąpi timeout albo mamy strumień z guzika, gdzie user ma produkuje zdarzenie kliknięcia, które np. w tym przypaku byłoby na równi z timeoutem
Gdy o tym myślę to trochę nie rozumiem czemu fenomenu reaktywnego programowania. Ta rzecz oczywiście upraszcza synchronizację, jest pomocne gdy dane pochodzą z wielu źródeł, ale ja w 90% sytuacji wybrałbym event listenera lub csp na mniejszą skalę niż pakować się we framework od reaktywnego programowania.
Zastanawiam się czego jeszcze nie widzę.
Czy takie strumienie ułatwiają projetkowanie aplikacji gdzie dochodzi do współpracy paru osób na tym samym widoku jednocześnie? Co o tym najbardziej decyduje?