[veranoo]

Pytanie do #frontend #react #javascript #programowanie

Jak budujecie aplikacje która komunikuje się z jakimś api, to używacie tzw: dto-sów bezpośrednio do widoku czy robicie jakąś warstwę nad tym i mapujecie?

[FiranMercury]

Nie potrafię odpowiedzieć na pytanie zadane przez Ciebie odpowiedziami tak skrojonymi.

Logikę do pobierania danych najlepszym patternem jest zawsze wyciągnięcie do osobnego modułu.

W komponencie odpowiadającym za widok najlepiej jest mieć rezultat przygotowany przez hook.

1.

[veranoo]

Logikę do pobierania danych najlepszym patternem jest zawsze wyciągnięcie do osobnego modułu.

@FiranMercury: Tu nie chodzi o logikę pobierania, tylko o interfejs obiektów, które pochodzą bezpośrednio z api. W większości przypadkach to jest samo i wielu myśli że to powielanie. Ale jest sytuacja gdzie api rozbija się wtedy na dwa endpointy, bo dwie rzeczy wylądowały w różnych mikroserwisach. Wtedy masz dwa dto, ale z puntu widzenia UI to się nic

[fujiyama]

@veranoo: to zależy.
W większości przypadków wystarczy Ci struktura, którą otrzmujesz z serwera. Możesz przecież ją sobie rozszerzyć ją o swoje pola czy nawet funkcje, które podstawisz potem do widoku.
Naprawdę to pytasz chyba czy używać redux-a.

[veranoo]

Naprawdę to pytasz chyba czy używać redux-a.

@fujiyama: Nie pytam o redux-a. Jak masz interfejs który masz zdefiniowany obok serwisu, np PostDto I pytanie gdzie go używasz. Jeśli używasz go w jakimś komponencie ui to znaczy że jesteś z nim mocno powiązany, a według mojej opinii nie powinieneś. Powinieneś mieć jakąś warstwę abstrakcji która odseparuje Ci jakoś te warstwy. Głupi przykład, na frontendzie macie camelCase a na backendzie snake_case, w

[wybacz]

@veranoo:

Głupi przykład, na frontendzie macie camelCase a na backendzie snake_case, w różnych językach standard jest inny. Jak to ze sobą pogodzisz.

w interceptorze

[veranoo]

@wybacz: To jeszcze ktoś używa axios-a w 2023? A później Item jest rozbijany na dwa enpointy i musisz orać całą apkę.

[krand]

@veranoo: idziesz tutaj za mocno w idealizm, to znaczy, ok, tak, posiadanie swojego modelu i mapowanie do niego to bez wątpienia lepsza praktyka sama w sobie, aczkolwiek nic nie jest za darmo i trzeba rozważyć za i przeciw, swoje modele i mapery to masa kodu do utrzymania, która zazwyczaj nie jest aż tak potrzebna, projekt musi być naprawdę duży i używanie ich naprawdę uzasadnione

dla mnie osobiście żaden z argumentów, które podałeś nie są wystarczające, żeby robić mapowanie:
a) argument o zmianie propsa czy czegoś innego w modelu - tak naprawdę od tego masz IDE, że zrobisz sobie refactor na modelu dto i ono pozmienia Ci wszędzie w kodzie odwołania
b) argument o "tym samym" obiekcie w 2 różnych api - szczerze? dla mnie to jest "incidental duplication", ok, może i struktura jest póki co taka sama, ale jednak pochodzi z dwóch różnych miejsc i z mojego doświadczenia zazwyczaj takie rzeczy z czasem się rozjeżdżają i nagle już nie dostajesz tego samego z dwóch mikroserwisów, więc uważam że lepiej mieć 2 osobne modele i komponent, który ich używa powinien "być tego świadomy", to znaczy "explicit" używać tych dwóch modeli
c) argumentu o konwencjach kompletnie nie rozumiem, przecież i tak Ty masz ownership nad dto i jest on w twoim codebasie, więc może mieć konwencje jakie chcesz i to tylko kwestia ustawienia narzędzia parsującego faktyczną wiadomość np. w

[wybacz]

@veranoo:

To jeszcze ktoś używa axios-a w 2023

nie, nikt xD

[veranoo]

@krand: Zgadzam się z Tobą, ale problem zaczyna się pojawiać gdy masz klika platform a jedno api. Pamiętam zawsze ile czasu zajmuje migracja api z v1 na v2. Chyba wykop też jest tutaj dobrym przykładem xD. Zmiana w api nie może nieść implikacji w UI, bo to proszenie się o kłopoty, mimo wszystko dużo osób tak robi i później przy migracjach powstaje problem. W aplikacjach androidowych, flutterowych, ios-wych oddzielanie dto

[veranoo]

@wybacz: Po co axios, jak masz natywnego fetch-a. Rozumiem że axios miał rację bytu dla XMLHttpRequest. Dzisiaj jedynie broni się interceptorami.

[fujiyama]

@veranoo: czemu miałbyś nie używać konwencji z backendu?
Piszesz jakieś uniwersalne komponenty, które chcesz wykorzystać w wielu projektach?
To wtedy masz swój model i dane z serwera musisz mapować. Wtedy nie ma wyjścia.
W innym przypadku nie wiem czemu miałbym stosować dwie różne notacje w projekcie.
Ilość kodu należy minimalizować, upraszczać transformacje etc.
Inaczej to potem kosztuje (wydajność aplikacji,

[AntyKuc]

@veranoo:

Po co axios, jak masz natywnego fetch-a. Rozumiem że axios miał rację bytu dla XMLHttpRequest. Dzisiaj jedynie broni się interceptorami.

Axios dla interceptorów i tworzenia customowych instancji API. Service dla danej domeny, który jest klasą w której są dostępne wszystkie endpointy wystawione przez BE dla tej domeny. DTO na returnie metody z klasy, tam sobie ustawiam dodatkowe pola, zmieniam nazwy, request też ma swoje DTO. Dzięki temu podejściu jeżeli

[veranoo]

@fujiyama: Przeczytaj mają odpowiedź dla kolegi krand, bo nie chcę mi się powtarzać.