Cześć
Jest sens łączyć tych 3 bibliotek wymienionych w temacie? Konkretnie zastanawiam sie nad immutable + Rx. W jednym i drugim sa funkcje które pomagają w operacjach na na obiektach i czy one się nie nakładają?
Jestem nowy w FRP i coś mnie trapi :P
Pozdrawiam
To sprawdź. Zrób projekt, który to łączy i zobacz jaki będzie tego wynik.
Tylko lepiej nie wrzucaj na produkcję, potraktowałbym to raczej jak czysto edukacyjny eksperyment.
Szczególnie, że jeśli nie znasz tych bibliotek dobrze, to będziesz musiał się ich nauczyć - a ucząc się naraz Reacta, Immutable i Rx na pewno stworzysz potworka i pełno brzydkiego kodu (co nie jest niczym złym, jeśli nie wrzucisz tego na produkcję tak jak większość programistów - niestety trend wrzucania na produkcję każdej nowości jest we frontendzie silny).
Jest sens łączyć tych 3 bibliotek wymienionych w temacie?
Pytanie chyba powinno brzmić: jaki jest sens używać którejkolwiek z tej biblioteki? Albo: jaki sens jest używać tych bibliotek w twoim projekcie? (swoją drogą nie napisałeś w ogóle co chcesz osiągnąć, a od tego należałoby zacząć).
z moich doświadczeń:
React pozwala robić komponenty i składać z nich interfejsy. Ma swoje wady, ale jest okej.
z Immutable korzystałem przy pracy z Redux, nawet okej było, żeby tworzyć nowy stan w reducerach, chociaż da się pracować i bez niej.
co do Rx - to z jednej strony jestem pod wielkim wrażeniem tej biblioteki, ile różnych opcji niesamowitych - z drugiej strony próg wejścia w nią jest wysoki, są koncepcje, które trzeba opanować (np. gorące i zimne obserwable), trudno się debuguje, za dużo magii pod spodem i ciężko zserializować te strumienie do JSON (np. żeby przesłać przez sieć).
Czyli ja w ogóle bym podchodził z rezerwą do Rx. Fajna biblioteka, ale raczej nie taka, którą bym wrzucał do projektu bez pomyślenia, bo jednak widzę, że ma ona dużo wad.
Szczególnie, że i tak problem do którego rozwiązywania potrzebny mi był Rx - czyli transformowanie asynchronicznych danych można rozwiązać również za pomocą zwykłego Vanilla JS, może pisząc trochę więcej boilerplate (ale w Rx też jest boilerplate)
Co do mieszania bibliotek, to akurat nie łączyłem Rx i Immutable - nie widzę sensu takiego łączenia, ale nie wykluczam, że może istnieć problem, który da się tak rozwiązać.
Generalnie w projekcie ktorym pracuje jest mercury most i mori. To mniejsze odpowieniki. Projekt przejalem po kims i na razie pracuje w innym obszarze. (Pisze tresty selenium) ale za jakis miesiac lub dwa bede developowal nowe funkcjonalnosci.
Wiec mam troche czasu i mnostwo kodu na ktorym moge sie wzorowac. Poprzedni jedyny programista odszedl i nie ma z nim kontaktu wiec rozkminiam wszystko co on napisal i staram sie zrozumiec idea. Ale Luke cos mi juz podpowiedziales.
Mercury do componentow. Most do operacji na asynchronicznych danych a mori do operacji na obiektach. Cos jak Angular + promise + lodash tylko ze koncepcja inna. Dobrze mysle?