Architektura reduxa.

Hej, mam pytanie o architekturę reduxa w kontekście react native, ale pewnie w normalnym react panują podobne zasady.

Wyobraźmy sobie ekran przedstawiający szczegóły itemu, który zawiera jakieś dane odnośnie samego itemu, odnośnie sprzedawcy i np itemy podobne do niego. Po dane musimy uderzyć do 3 różnych zapytań z backendu. I teraz tak .. w reduxie powinniśmy trzymać dane przychodzące z backendu wraz z aktualnym stanem danego zapytania (success, error, in_progress, init) czy już zmapowane w reducerach wyniki tych zapytań na modele typowo widokowe ? Często te modele widokowe są bardzo podobne do tych przychodzących z serwera. Tylko teraz tak .. jeśli mamy jeden model danych trzymających wszystkie info potrzebne przez ten ekran detaili itemu (o samym itemie, o sprzedawcy, o innych podobnych) to ten reducer będzie wielki. Z drugiej strony możemy zawsze ten model rozbić na 3 osobne modele i trzymać w storze osobno i dany widok renderować nie na podstawie 1 modelu tylko 3 różnych. Z innej też strony jeśli w reduxie trzymamy nie modele serwerowe tylko te widokowe, a każdy widok czyli komponent ma swój własny taki model to ten store reduxowy będzie wielki.

Prośba o wskazówki, serdecznie pozdrawiam !

Narysujesz diagram, co próbujesz osiągnąć? Albo jakiś pseudokod? Mam wrażenie, że coś prostego, ale w formie suchego tekstowego opisu wydaje się to być bardziej skomplikowane niż jest.

to ten reducer będzie wielki.

Nie musi być wielki. Np. możesz rozbić reducer na wiele małych reducerów używając funkcji combineReducers. Albo w inny sposób.

No dobra, to prosto .. jest ekran szczegółów itemu, który pokazuje jakieś dane o tym itemie, o sprzedającym i listę podobnych itemów - mam 3 zapytania do serwera po te dane.
Czy powinienem trzymać w storze reduxa bezpośrednio to co przyjdzie z serwera i w komponencie używać tego co potrzebuję czy raczej w storze trzymać już przerobione dane z serwera ? Bo np dany komponent nie wykorzystuje wszystkich danych, które przyjdą z backendu.

Ja wiem jak działa sam redux - pytam bardziej o dobre praktyki.

Według mnie, pierwsza dobra praktyka to o ile nie budujesz facebooka i wiele zespołów nie rozwija tej samej aplikacji to zrób niezależne komponenty i nie używaj reduxa. Komponent niech pobiera dane do swojego stanu.

Redux powinien być wykorzystywany jedynie w scenariuszach gdzie wiele komponentów modyfikuje i odświeża ten sam stan. Przykładowo skomplikowany edytor tekstu. Gdy chcemy po zmianie przeliczyć statystyki na temat tekstu.

Wówczas to oznacza, że w reduxie powinien być wyłącznie oryginalny stan. A nie specyficzny dla komponentu.

Niestety w twoim przypadku redux to srogi overenginering i utrata podstawowej własności reacta jaką są niezależne komponenty.

@nie100sowny:

Zgadza się, ale to nie jest moja apka po godzinach, tylko wyszło w robocie tak w projekcie, że nie ma komu robić apki mobilnej, bo część frontowa daleko za murzynami w porównaniu z backendem i no postanowiłem wspomóc...

A chcę jakieś dobre praktyki do projektu wprowadzić, ale no reduxa już wywalać nie będę :D

Trochę rozwinę moją odpowiedź. W kodzie będziesz miał taką ewolucję:

1. Jeśli możesz to stanowy komponent to najprostsze rozwiązanie i warto o tym myśleć dopóki dane mają marginalne znaczenie z punktu widzenia innych komponentów czy logiki jaka jest po stronie frontu. Ja najczęściej używam takie komponenty do pracy z inputami, plikami i wydzielonymi miejscami, które wykonują bardzo dużo aktualizacji.

2. Jeśli dane będziesz używał do przeliczania czegoś, jeśli do tych danych będą odwoływać się inne komponenty (nie tylko dzieci) to warto przenieść te dane do redux. W takiej sytuacji dane masz oddzielone od widoków, i to jest też dobra rzecz jeśli logika w aplikacji po stronie frontu jest bardziej złożona. Wtedy możesz łatwiej pisać logikę, która pomija aspekt wyglądu.

3. By zawęzić to co powinien widzieć komponent możesz użyć selectory. One są dobre jeśli Twoja dane wymagają dodatkowego przeliczenia/agregacji nim zostaną wyświetlone. https://redux.js.org/recipes/computing-derived-data Być może to też jest opcja, którą warto byś przemyślał.

4. Z biegiem czasu jak model stanie się większy to pisanie selectorów stanie się uciążliwe. To będzie praca z modelem w redux będzie podobna w bazach. Gdy masz dane nierelacyjne (opis przy użyciu różnych obiektów) to selekcje jakie tworzysz muszą uwzględniać tą strukture, na skutek czego piszesz pod nie odpowiednie pętle. Składasz parę wyników w jeden itp. Taki kod jest utrapieniem, ponieważ nie widzisz wszystkich przypadków o które będziesz pytał, a nowe zapytanie może oznaczać kolejny nakład prac (wymagający nie raz zmiany modelu po stronie redux).

Problemem wtedy nie jest tylko to, że schodzi Ci się na tym dłużej, ale również tracisz wydajność, ponieważ piszesz pętle, a tak naprawdę pasowałoby mieć w paru miejsach indeks. Ostatecznie uzyskujesz też kruchy kod, który na skutek zmiany modelu wymaga wielu poprawek w selektorach (bo pętla szyta pod konkretny przypadek jest mniej elastyczna) .

Znacznie lepiej pisze się kod, gdy zamiast pętli mówisz co chcesz uzyskać - tak jak w przypadku SQL. Wtedy zamiast pisać pętle, piszesz deklaratywnie zapytanie o dane - a skoro więcej siedzisz na backendzie to doskonale powinieneś rozumieć tę różnicę. Ja w moim przypadku używam datascript, który też jest możliwy w świecie JS. No i też wtedy nie trudno wtedy współdzielić te zapytania i te prostsze przekształcać w bardziej złożone.

Dzięki za odp .. u mnie w pracy panuje przekonanie, że róbmy wszystko pragmatycznie i skoro w użyciem reduxa fajnie wygląda trzymanie wszystkich danych z backendu to tak róbmy .. Jestem tylko ciekawy czy jak będziemy w storze trzymać wszystkie dane, które pobierzemy z serwera to czy apka nie zwolni. Dodatkowo jak mam ekran szczegółów itemu to za każdym razem muszę go na wejściu resetować bo siedzą stare dane ze stora odnośnie itemu, który wyświetliłem przed chwilą.