Code review aplikacji napisanej w Reakcie przez junior developera (część 2/10 - teoria i podział)

Moim gościem był Mati, junior developer, który w ramach nauki stworzył aplikację - listę zakupów. W nagraniu przechodzimy do części praktycznej, w której tłumaczę teorię oraz pokazuję, jak podzielić aplikację na części shared i features. Zdradzam także sposób, w jaki można zarządzać layoutami w projekcie. Zapraszam do oglądania!

Linki:

00:00:00 - start
00:00:26 - wstęp
00:01:22 - teoria
00:18:37 - katalog shared
00:42:34 - grupowanie importów
00:45:34 - katalog features
00:58:05 - layouty
01:14:12 - zakończenie

[MrJ-ihmw]

Jaka jest przewaga tego podejścia, że w projekcie react robimy katalog shared > ui > Burger w którym umieszczamy pliki :
index.js (export * from './public-api.js'
public-api.js (import Burger from './Burger' export Burger from './Burger')
Burger.js (z kodem exportującym komponent Burger)

Dlaczego nie exportować bezpośrednio z burgera albo bezpośrednio z public-api.js? Rozumiem, że to chodzi o to, że jakby było więcej komponentów Burger ale w takim razie dlaczego pośredniczący plik public-api.js a nie od razu index.js?

[kbek]

Cześć! Jaka jest różnica pomiędzy tworzeniem plików index.ts, a absolute imports? Dzięki z góry 😊

[defres]

Czy atomic design w folderze shared to overkill ?

[ukaszs]

Mam wrażenie że coś się pomieszała logika przy tłumaczeniu architektór.
Główny klucz to kierunki i rodzaje zależności między kawałkami kodu.

Polecam najpierw omówić warstwy konkretne, a potem warstwy abstrakcyjne jako wariant warstw.
Fajnie pokazane że w warstwach są zależności w jednym kierunku.

Np na początku powiedzmy jest serwis który zależy od API REST albo GraphQL ale jakiegoś konkretnego.
A potem jest dodawana abstrakcja: np jeden kod generuje zapytania REST, inny GraphQL, ale można dać nad tym interface i podmieniać implementacje bo jest abstrakcja.
Abstrakcyjne warstwy to dalej warstwówka.

Do heksagonu/port adapters brakuje informacji kluczowej. Głównym pomysłem na tę architekturę jest to że kod domenowy i logika domenowa jest kluczową częścią.
I nie powinno mieć konkretnych zależności ani do persystencji (calle API, bazy danych itp.) ani do prezentacji (konkretne stronki).
Bo niezależnie od szczegółów API, czy to firebase czy SQL czy pliki. Czy to będzie wyświetlać react czy angular.
Logika np listy zakupów jest taka sama, wiec ten kod nie powinien ulegać zmianom jak zmieniają się szczegóły techniczne.

Oczywiście w każdej technologii na jakimś etapie są potrzebne konkretne zależności żeby faktycznie odczytać dane albo wyświetlić je na ekran.
Ale te zależności powinny być pochowane za interfejsy i umożliwić w miarę łatwą podmianę jakby się te warstwy zmieniły.
Zachodzi też inwersja zależności w tym sensie że warstwa domenowa nie używa API bezpośrednio,
tylko definiuje jakie operacje ona chce zrobić w formie interfejsów, a potem faktyczne API zależy od warstwy domenowej i implementuje te interfejsy.
W klasycznej warstówce zależność jest odwrotna - domena musi się dostosować do API.

Prezentacja czyli stronki tak samo używają domeny w obu architekturach.
Tylko w heksagonie jest większy nacisk żeby nie wpychać szczegółów technicznych do kodu domeny.

(W praktyce zależność jest w obie strony, bo API musi umożliwić kluczowe operacje domenowe żeby było poprawnie,
ale logika musi dostosować się do API z powodów wydajnościowych
a różne wymagania i konwencje z frameworków troche przeciekają dodomeny)

Np zmiana API z REEST na GraphQL nie powinna nic zmienić w kodzie logiki domenowej.
Tak samo np zmiana Angulara na Reakta nie powinna nic zmienić w logice domenowej.
(lista zakupowa dalej powinna mieć tę samą logikę, wiec ten kod nie powinien się zmienić)
Za to zmiana logiki domenowej może wymagać dodania nowych calli do API albo poprawy formularzy.

W praktyce to różnie bywa ale co najmniej interfejsy warto mieć żeby nie przemycać za dużo zależności i konwencji konkretnych frameworków.

[AvatarEightSix]

Cześć. Bardzo fajne są te odcinki. Wyciągam z nich dużo przydatnych rozwiązań. btw. co to za theme dla vs code? Wygląda bardzo schludnie i nie razi po oczach :)

[ambrozykleks]

Bardzo fajne, ale please, nie piszcie w TS, bo nie kumam :)

[robertmazurowski]

Zjechać młodego, żeby zapomniał jak się nazywa. Do przeczytania Biblia SQL w ramach rozgrzeszenia? A dlaczego biblia SQL, żeby poszerzać horyzonty przez tortury. :D