Struktura plików w projekcie

Struktura plików jest istotnym elementem współczesnego budowania aplikacji internetowych. Warto zadbać o przejrzystość naszych plików i uporządkować je tak, aby powrót do nich po czasie sprawiał jak najmniejsze problemy. Dzięki temu ciężej będzie również pogubić się w tworzeniu kodu.

Dzisiejszy przesyt frameworkami i rozwiązaniami w aplikacjach sprawił, że w projektach wykorzystujemy masę różnych plików zachowujących swoją funkcjonalność. Dlatego tak ważne jest, żaby te pliki sensowanie i w sposób przejrzysty posegrogować. Dzięki temu nie zatracimy się w tych plikach podczas rozrastania projektu i łatwiej będzie wrócić do niego po czasie. Zanim jednak zaczniemy od omawiania tego zagadnienia, chciałbym zaznaczyć, że nie należy przyjmować wzorców budowania projektów jako sztywny zero-jedynkowy zbiór zasad, któego mamy się trzymać zawsze i wszędzie. Sami twórcy Reacta piszą, że nie ma jednej, jedynej metody i sposobu na utrzymanie plików. Wspominają tylko o pewnych utartych podejściach, które społeczność oraz deweloperzy sami z czasem zdefiniowali. Ponadto, nie zawsze warto wprowadzać pełną, rozwiniętą architekturę do projektu. Jeżeli jest on mały lub nie koreluje z zaproponowanymi modelami, czasem warto zrezygnować z któregoś z nich i skupić się na pisaniu kodu - architektura wtedy przyjdzie z czasem. Jeśli nie, to najwidoczniej nie wpisuje się to z potrzebami projektu.

Domain Driven Design

Pierwszy termin jakim się posłuże jest Domain Driven Design (DDD). Jest do podejście polegające na budowaniu architekury projektowej w oparciu na jak nawiększe odzwierciedlenie rzeczywistości biznesowej. Mamy tu doczynienia z domenami i ich kodem. Najczęściej domeny przedstawiają otoczenie jednego z procesów odbywających się w ramach funkcjonalności aplikacji. Przykładowo, w ramach projektu tworzymy 3 funkcjonalności, które są niezależne od siebie. Dla każdej z nich stworzymy 3 podkatalogi w katologu głównym domain. A w nich bezpośrednio umieścimy tak pliki z kodem odpowiadające za niezależne funkcje domeny:

zdjęcie tematyczne
przykładowa struktura domenowa - źródło justjoin.it

Na pierwszy rzut oka widać jak taka czysta struktura jest przejrzysta i czytelna. To podejście nie jest bardzo często wykorzystywane jeżeli chodzi o Front End, ale ma swoje zalety, o których powiem niebawem. Po więcej o DDD odsyłam do artykułu portalu justjoin, który w sposób szczegółowy wyjaśnia na czym polega Domain Driven Design.

Atomic Design

Frameworki oparte są o komponenty, które są nieodłącznym usprawnieniem pisania kodu do aplikacji frontendowej. W miarę rozrastania aplikacji tych komponentów będzie coraz więcej, a to znaczy, że pakowanie ich do jednego katalogu components mija się z celem. Z pomocą przychodzi nam podejście Atomic Design po raz pierwszy zdefiniowane przez Brada Frosta. Atomowa architektura komponentów polega na katagoryzowaniu ich na 5 składowych:

  • Atomy
  • Molekuły
  • Organizmy
  • Szablony (Templates)
  • Widoki (Pages)

Wszystkie te składowe składają się z ich mniejszych części, i tak - molekuły będą składać się z atomów, a szablony z wszystkich ich niższych komponentów. Nie oznacza to, że nie możemy umieścić komponentu-atomu bezpośrednio w organizmie czy szablonie, ale idea polega tu na hierarchii komopnentów, co usprawnia ich tworzenie. Dla przykładu, atomem może być komponent Button lub element formularza, np. Input. Logiczne podejście mówi więc, że organizmem będzie sam formularz Form, który zbudowany będzie z wielu atomów lub molekuł. Pierwsze 3 najniższe składowe, czyli atomy, molekuły i organizmy stanowią właściwe komponenty, z których zbudowana jest aplikacja webowa. Szablony przedstawiają Templaty, które zapewniają na przykład globalne style, context lub store, a Pages lub Views są to właściwe wyświetlane strony, z umieszczonym finalnym kontentem i przezentacją treści. Architektura Atomic Design może prezentować się w sposób następujący:

zdjęcie tematyczne
architekura Atomic Design

Jak widzisz na grafice, ważnym jest, by zachować również przejrzystość komponentów jeżeli chodzi o ich podział - jeden komponent - jeden katalog - i rozdzielić jego podfunkcjonalności na oddzielne pliki. Czyli odseparować styl od głównego liku JS, tak samo jak testy.

Jakie podejście wybrać?

Skoro są 2 główne modele projektowania struktur, co powinniśmy wybrać? Wcześniej wspomniałem, że DDD rzadziej spotyka się na froncie. To prawda, bo paradygmat został ten stworzony raczej do języków backendowych, a front rządzi się przecież swoimi prawami.  Nie znaczy to jednak, że na froncie nie ma dużo istotnych podobieńst i naleciałości z DDD. Wcześniej wspomniałem również, że nie ma tu podejścia zero-jedynkowego. Ważne jest, by spojrzeć na architektiurę z perspektywy potrzeb projektu, ale też z tym, czym wygodniej będzie się pracować. Tutaj napotykamy na zatarcie dwóch podejść, w którym nic nie jest sztywne. Co tutaj mam na myśli?

Przypuśćmy, że musimy zaprogramować komponent formularza. Jasnym jest więc, że będzie to przedstawiciel Molekułu lub Organizmu (zależnie od zaawansowania i logiki komponentu - tak jak wspomniałem, algebra Boole'a nie ma tu zastosowania) w metodyce Atomic Design. A jego elementy (inputy, checkboxy itd.) będą Atomem lub Molekułą. Zamiast używania tutaj sztywnej reguły Atomic Design i umieszczania katalogów tych komponentów w katalogu atoms, umieścimy je w katalogu Forma i nazwiemy z przedrostkiem oznaczającym dany formularz. Na przykład będzie to wyglądało tak:

zdjęcie tematyczne
przedstawienie miksu Atomic Design oraz DDD

Możemy tak zrobić na przykład jeżeli formularz będzie miał swoje indywidualne podkomponenty, dziedziczące style lub nawet logikę z komponentów bazowych, których pliki będą umieszczone klasycznie w folderze składowych atmowych. Daje nam to ogromną czytelność i w takiej strukturze naprawdę trudno się po czasie nie połapać. Zaznaczam jednak, że jest to przykład reprezentatywny, powstał na potrzebę. Nie wiem czy faktycznie ustanawianie właśnie takiej struktury byłoby dobre, mam jednak nadzieję, że rozumiesz, co tutaj chcę przekazać.

Warto wspomnieć tutaj także o innych plikach, które powstają na potrzebę pisanego projektu. Istotnym jest, żeby nie tylko komponenty dzielić w sposób przejrzysty i klarowny, ale i wszystko inne co się w workspace może potencjalnie znaleźć, czyli api, helpery, store, hooki, context, pliki globalne, assety (grafiki wektorowe oraz rastrowe) i wszystko co powstaje pod szyldem projektu. Dodatkowo nasz edytor przypisze ikonki do nazwanych katalogów. Dzięki temu otrzymamy niesamowicie przejrzystą i czytelną strukturę projektu, której nie powstydziłby się żaden senior.

zdjęcie tematyczne
pełna struktura projektu frontendowego

Konkluzja

Myślę, że udowodniłem, że warto wprowadzać do swoich projektów strukturę segragacji oraz organizacji plików. Daje do tylko same zalety i jest niesamowicie ułatwiające w czytaniu deweloperskiej aplikacji. Dodam, że opisywałem tu, rzecz jasna, podejście, które wprowadzamy w plikach źródłowych (najczęściej jest to katalog src) oraz, że podejście to można śmiało wprowadzić w życie czy to w React czy Vue, czy to w jakimkolwiek frontendowym projekcie. Pewnie z małymi odstępstwami, ale jak to Dan Abramov kiedyś powiedział:

move files around until it feels right

Źródła

© Damian Kalka 2021
Wszelkie prawa zastrzeżone