Aktywne Wpisy
WielkiNos +69
Gdyby kogoś zastanawiało dlaczego kobiety na tinderze nie odpisują to tak wygląda 90% wiadomości od facetów. W krótkim czasie każdy się staje potencjalnym zbokiem, który chce się tylko dobrać do majtek.
#tinder #podrywajzwykopem #logikaniebieskichpaskow
#tinder #podrywajzwykopem #logikaniebieskichpaskow
WielkiNos +237
Prawdziwe piekło kobiet, z którego nikt nie zdaje sobie sprawy - przygotowywanie wesela. Tylko kobieta, która to robiła zrozumie tą samotność i brak zrozumienia, które wtedy człowieka dotykają.
A wszystko tylko dlatego, że nikt w Polsce nie dba o prawa kobiet i je zmusza do organizacji wesel.
#pieklokobiet #p0lka #wesele #bekazrozowychpaskow #heheszki
A wszystko tylko dlatego, że nikt w Polsce nie dba o prawa kobiet i je zmusza do organizacji wesel.
#pieklokobiet #p0lka #wesele #bekazrozowychpaskow #heheszki
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?
Co wybierasz?
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. Boilerplate metod komunikacji z API osobno,
2. Metoda do obsługi konkretnego endpointu osobno,
3. Ewentualna funkcja mapująca dane osobno,
4. W przypadku reacta hook, który to wszystko sklei i wyrzuci gotowe dane + wykona rerender elementu
@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 nie
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.
@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 różnych
w interceptorze axiosowym:
convertToCamelCase(response.data, { deep: true })
przy responsieconvertToSnakeCase(response.data, { deep: true }),
i przy requescieno a potem co? typujesz response dla kazdego endpointa np.
Item[]
i komponent sobie przyjmujeitems: Item[]
dla mnie osobiście żaden z argumentów, które
nie, nikt xD
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, czas refaktoru).
Automappery używane na backendzie (np. Java/.NET) jest często przyczyną istotnego
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 endpoint