6.12.20225 min
Thomas Sentre

Thomas SentreFullstack Web Developer | Cloud Specialist

Struktura projektu w React - jak powinna wyglądać

Sprawdź, jaka skalowalna i łatwa struktura najlepiej sprawdza się w codziennej pracy programisty React.

Struktura projektu w React - jak powinna wyglądać

Odpowiednia struktura projektu może mieć ogromny wpływ na to, czy projekt jest udany pod względem zrozumienia bazy kodu, elastyczności i utrzymania. Projekty, które nie są dobrze zorganizowane i utrzymywane, mogą szybko przerodzić się w jeden wielki bałagan i fatalną spuściznę, z którą nikt nie będzie chciał w przyszłości pracować.

Pokażę Ci teraz strukturę, którą bardzo często wykorzystuję w swoich projektach, oraz wyjaśnię, na czym polega. Ta struktura powinna być dobrym punktem wyjścia dla aplikacji na dużą skalę i możesz ją rozbudować w zależności od potrzeb projektu. Oto struktura src, którą mogę polecić dla większości projektów:


Omówmy foldery od początku do końca.


api

Na początek folder api, który będzie zawierał warstwę API naszej aplikacji. Będziemy tutaj mieli metody, które odpowiadają za wykonywanie żądań API oraz komunikację z serwerem.


assets

Folder aktywa zawiera czcionki, obrazy i video. W czcionkach możesz zachować dowolne niestandardowe czcionki oraz kroje czcionki. W obrazach przechowuj wszystkie obrazki używane w całej aplikacji.


komponenty

Katalog komponentów zawiera dwa katalogi: wspólny i przejściowy. Katalog wspólny będzie zawierał wszelkie komponenty wielokrotnego użytku, które są powszechnie używane w całej aplikacji.

Na przykład przyciski, komponenty formularzy, komponenty związane z typografią i tak dalej. Wszelkie komponenty, które nie są tak powszechne, zostałyby umieszczone wewnątrz komponentów przejściowych.


hooki

Katalog z hookami, jak sama nazwa wskazuje, przechowywałby wszelkie niestandardowe i wielokrotnego użytku hooki. Zauważ, że hooki, które nie są tak naprawdę wielokrotnego użytku, ale są powiązane z konkretną funkcją, powinny być umieszczone w tym samym katalogu co ta funkcja.

Na przykład wyobraźmy sobie, że mamy komponent formularza newslettera, który zawiera formularz do zapisania użytkownika na newsletter. Ten komponent mógłby wykorzystywać hook o nazwie useNewsletterSignup, który obsługiwałby zapisywanie użytkownika.

Taki hook nie powinien być umieszczony w globalnym katalogu src/hooki, ale raczej lokalnie, ponieważ jest ściśle powiązany z komponentem NewsletterForm. Mogłoby to wyglądać w ten sposób:


Najlepiej jest zachować logikę, która jest powiązana tak blisko, jak to możliwe, do miejsca, w którym jest używana. W ten sposób nie będziemy niepotrzebnie dodawać więcej kodu do globalnego folderu hooków, który powinien zawierać tylko hooki wielokrotnego użytku. To samo dotyczy innych funkcjonalności, takich jak pomocnicy, usługi itp.


kontekst

Katalog kontekstowy powinien zawierać wszelkich dostawców stanu kontekstu na poziomie globalnym.


layout

Katalog układu, jak sama nazwa wskazuje, powinien posiadać komponenty, które zapewniają różne układy dla Twoich stron. Przykładowo, jeśli budujesz aplikację typu dashboard, możesz renderować różne układy w zależności od tego, czy użytkownik jest zalogowany, czy nie.


config

W katalogu config możesz umieścić dowolne pliki konfiguracyjne runtime’u dla swojej aplikacji i usług stron trzecich. Na przykład, jeśli używasz usługi takiej jak Firebase lub OIDC do uwierzytelniania, będziesz musiał dodać pliki konfiguracyjne i użyć ich w swojej aplikacji.

Upewnij się, że nie mylisz configu ze zmiennymi środowiskowymi, ponieważ wszystko, co znajdzie się tutaj, będzie obecne w pakiecie instalacyjnym.


stałe

Tutaj możesz umieścić wszelkie stałe zmienne, które są używane w całej aplikacji. Dobrą praktyką jest pisanie wielkich liter w celu odróżnienia ich od innych zmiennych i stałych zlokalizowanych w Twojej aplikacji. 

Poniżej znajdziecie kilka przykładów definiowania i używania stałych:


Definiowanie stałych osobno

// in constants/appConstants.ts
export const APP_NAME = 'Super app'
export const WIDGETS_LABEL = 'Widgets'

 

// Somewhere in your app 
import { APP_NAME, WIDGETS_LABEL } from '@/constants/appConstants' 
console.log(APP_NAME) 

 

// You can also grab all named exports from the file 
import * as APP_CONSTANTS from '@/constants/appConstants' 
console.log(APP_CONSTANTS.WIDGETS_LABEL) 


Definiowanie powiązanych stałych w jednym obiekcie

// in constants/appConstants.ts 
// Create an object with constant values 
export const apiStatus = { 
IDLE: 'IDLE', 
PENDING: 'PENDING', 
SUCCESS: 'SUCCESS', 
ERROR: 'ERROR' 
} 

 

// Somewhere in your app
 import { apiStatus } from '@/constants/appConstants' 
console.log(apiStatus.PENDING) 


pomocnicy

Wszelkie narzędzia i małe funkcje wielokrotnego użytku powinny trafić tutaj — na przykład funkcje do formatowania daty, czasu itp.


intl

Ten katalog jest opcjonalny. Dodaj go, jeśli aplikacja wymaga wsparcia internalizacji. Intl, znany również jako i18n, polega na wyświetlaniu zawartości aplikacji w formacie odpowiednim do ustawienia lokalnego użytkownika.

Zawartość ta może obejmować między innymi przetłumaczony tekst lub określony format dat, czasu i waluty. Przykładowo, Wielka Brytania używa formatu DD/MM/YYY, a USA używa MM/DD/YYY.


usługi

W większych aplikacjach możemy mieć złożony kod logiki biznesowej, który jest używany w kilku różnych miejscach. Kod taki jak ten jest dobrym kandydatem do wyodrębnienia z komponentów i umieszczenia go gdzieś indziej, a folder usług będzie do tego dobrym miejscem.


pamięć

Folder pamięci odpowiada za pliki związane z globalnym zarządzaniem stanami. Istnieje wiele rozwiązań do zarządzania stanem, które można wykorzystać w projektach Reacta, takich jak Redux, Zustand, Jotai i wiele wiele innych.


style

W folderze style można umieścić style globalne, zmienne, style motywów i nadpisania.


typy

Tutaj możesz umieścić dowolne typy globalne i udostępniane. Dzięki temu zaoszczędzisz czas i łatwiej udostępnisz kod i typy TypeScript, których potrzebujesz ty i twój zespół.


widoki

Zazwyczaj katalog widoki zawiera tylko komponenty tras/stron. Przykładowo, jeśli mamy stronę, która ma pozwolić użytkownikom na przeglądanie produktów, mielibyśmy komponent Products.tsx w folderze widoki, a odpowiadająca mu trasa mogłaby wyglądać mniej więcej tak:

<Route path=”/projects” element={<Products />} />


Jest jednak powód, dla którego powiedziałem „zazwyczaj”. Wiele aplikacji posiada komponenty trasy w widokach, a reszta komponentów dla niej umieszczona jest w folderze komponentów. To podejście może działać dla małych i średnich aplikacji, ale jest znacznie trudniejsze do zarządzania i utrzymania, gdy liczba stron i komponentów rośnie.

Podsumujmy

Wybór odpowiedniej struktury folderów nie jest łatwym zadaniem. Musisz uzgodnić z zespołem strukturę, która pasuje do aplikacji, a to, co może odpowiadać jednej potrzebie, może nie odpowiadać innej.

Struktura powinna być utworzona tak, aby była przydatna przez kolejne lata. A Ty co zrobiłbyś inaczej, aby zapewnić dobrą, możliwą do utrzymania strukturę? Daj znać w komentarzach!


Oryginał tekstu w języku angielskim przeczytasz tutaj.

<p>Loading...</p>