0Pricing
Frontend Academy · Lekcja

Struktura folderów według funkcji

Zorganizuje Pan/Pani kod według domen funkcjonalnych zamiast typów, umieści testy, style i komponenty obok siebie oraz wymusi granice za pomocą eslint-plugin-boundaries.

Struktura folderów według funkcji to bezpłatna lekcja Frontend Academy na CoddyKit. To lekcja 4 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Frontend Academy, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Frontend Academy zawiera 4 lekcji w sumie.

Dwa sposoby organizacji kodu

Kod można grupować według typu (components/, hooks/, services/, types/) albo według funkcji (auth/, checkout/, dashboard/ — każdy folder zawiera własne komponenty, hooki itd.). Podejście oparte na funkcjach sprawdza się lepiej w aplikacjach średniej i dużej wielkości.

Podejście oparte na typach — domyślna pułapka

Klasyczna struktura z tutoriali Reacta grupuje wszystko według typu. Słabo skaluje się w większych projektach: każda zmiana pliku dotyka wielu niezwiązanych ze sobą folderów, a „znajdź cały kod checkout” oznacza przeszukiwanie całego drzewa za pomocą grep.

// Type-based (avoid for large apps):
src/
  components/
    Button.tsx
    LoginForm.tsx
    CartItem.tsx
  hooks/
    useAuth.ts
    useCart.ts
  services/
    auth.ts
    cart.ts
  types/
    User.ts
    CartItem.ts

Struktura oparta na funkcjach

Wszystko, co jest związane z daną funkcją, należy grupować w jednym folderze. Kod łatwo znaleźć, łatwo usunąć i łatwo zrozumieć.

src/
  features/
    auth/
      LoginForm.tsx
      SignupForm.tsx
      useAuth.ts
      auth.service.ts
      auth.types.ts
      auth.test.tsx
    cart/
      CartItem.tsx
      CartSummary.tsx
      useCart.ts
      cart.service.ts
      cart.types.ts
  shared/
    components/
      Button.tsx
    hooks/
      useDebounce.ts

Współlokowanie wewnątrz funkcji

Folder funkcji zawiera komponenty, hooki, serwisy, typy i testy — cały kod potrzebny dla danej domeny. Nowy deweloper chce zrozumieć auth? Otwiera auth/. Chce usunąć auth? Usuwa ten folder.

Kod współdzielony a kod funkcji

Kod używany przez co najmniej 2 funkcje należy przenieść do shared/ (lub lib/). Kod używany przez jedną funkcję powinien pozostać w jej obrębie. Należy oprzeć się pokusie wydzielania kodu tylko dlatego, że „może później da się go ponownie wykorzystać” — warto poczekać na drugie użycie.

Zasady granic między funkcjami

Funkcje nie powinny importować się bezpośrednio nawzajem. Jeśli dwie funkcje muszą współdzielić kod, współdzielony fragment należy przenieść do shared/. Jeśli muszą się koordynować, należy użyć zdarzeń lub współdzielonego store’a na poziomie aplikacji.

Wymuszanie granic za pomocą ESLint

Należy użyć eslint-plugin-boundaries lub eslint-plugin-import, aby wymusić zasadę: funkcje mogą importować kod z shared, ale nie od siebie nawzajem.

// .eslintrc.json
{
  "plugins": ["boundaries"],
  "settings": {
    "boundaries/elements": [
      { "type": "feature", "pattern": "src/features/*" },
      { "type": "shared",  "pattern": "src/shared/*" }
    ]
  },
  "rules": {
    "boundaries/element-types": ["error", {
      "default": "disallow",
      "rules": [
        { "from": "feature", "allow": ["shared"] },
        { "from": "shared",  "allow": ["shared"] }
      ]
    }]
  }
}

Publiczne API każdej funkcji

Każda funkcja udostępnia publiczne API za pośrednictwem features/auth/index.ts. Pozostały kod importuje moduły z '@/features/auth', a nie ze ścieżek wskazujących na wnętrze funkcji. Dzięki temu można zmieniać implementację wewnętrzną bez psucia kodu korzystającego z API.

// features/auth/index.ts
export { LoginForm } from './LoginForm';
export { useAuth } from './useAuth';
export type { User, AuthState } from './auth.types';

// Consumers:
import { LoginForm, useAuth } from '@/features/auth';
// NOT: import { LoginForm } from '@/features/auth/LoginForm';

Zagnieżdżanie podfunkcji

Duże funkcje mogą zawierać podfoldery: dashboard/widgets/, dashboard/charts/. Należy unikać zagnieżdżania głębszego niż 2–3 poziomy — wyszukiwanie staje się wtedy uciążliwe.

Gdzie umieszczać trasy

Strony i trasy mogą znajdować się w głównym folderze pages/ lub routes/. Są one cienką warstwą — pobierają komponenty i hooki z funkcji oraz składają je w całość.

src/
  pages/
    Dashboard.page.tsx   // composes Dashboard widgets from features/dashboard/
    Cart.page.tsx        // composes from features/cart/
  features/
  shared/

Migracja istniejącej aplikacji

Należy zacząć wyłącznie od nowych funkcji — nowy kod umieszczać w features/. Nie należy refaktoryzować wszystkiego naraz. W miarę pracy ze starymi plikami można stopniowo je przenosić. Reguły granic ESLint zapobiegają regresji w nowej strukturze.

Kiedy podejście oparte na typach nadal się sprawdza

W bardzo małych aplikacjach (poniżej 30 komponentów) lub bibliotekach podejście oparte na typach jest w porządku. Na podejście oparte na funkcjach warto przejść, gdy tylko pojawią się odrębne domeny biznesowe (auth, checkout, billing, settings).

Szybkie sprawdzenie

Jaka jest główna korzyść organizacyjna z grupowania kodu według funkcji zamiast według typu pliku?

Podsumowanie: struktura oparta na funkcjach

features/ zawiera kod właściwy dla domen, a shared/ — narzędzia współdzielone między funkcjami. Każda funkcja udostępnia publiczny index.ts. Funkcje nie importują się wzajemnie — korzystają wyłącznie z shared. Granice należy wymuszać za pomocą eslint-plugin-boundaries. Strony i trasy składają funkcje w całość. Migrację należy przeprowadzać stopniowo. Podejście oparte na typach jest odpowiednie dla małych aplikacji.

Często zadawane pytania

Czy lekcja „Struktura folderów według funkcji” jest bezpłatna?

Tak — pełny tekst „Struktura folderów według funkcji” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Frontend Academy, przejdź na CoddyKit PRO. Kurs Frontend Academy zawiera 4 lekcji w sumie.

Co nauczysz się w „Struktura folderów według funkcji”?

Zorganizuje Pan/Pani kod według domen funkcjonalnych zamiast typów, umieści testy, style i komponenty obok siebie oraz wymusi granice za pomocą eslint-plugin-boundaries. Ćwiczysz Frontend Academy z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Frontend Academy?

Nie wymagamy żadnego doświadczenia. Frontend Academy w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 4 z 4.

Ile czasu zajmuje lekcja „Struktura folderów według funkcji”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Frontend Academy?

Tak. Każda lekcja Frontend Academy zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

  1. Atomic Design: atomy, molekuły i organizmy
  2. Konfiguracja monorepo z Turborepo
  3. Mikrofrontendy: Module Federation
  4. Struktura folderów według funkcji
← Powrót do Frontend Academy