Instruction file imported from GrzSwa/wink_chat (.cursor/rules/project-struct.mdc). Copyright stays with the author.

Struktura Projektu Flutter z Riverpod

Opis katalogów:

• lib/: Zawiera cały kod Dart aplikacji.

• lib/main.dart: Główny plik startowy. Konfiguruje i uruchamia aplikację, zazwyczaj umieszczając ProviderScope w drzewie widżetów, aby zainicjować system Riverpod.

• lib/src/: Standardowy katalog dla kodu źródłowego. Używany do grupowania głównej logiki aplikacji.

• lib/src/features/: Katalog, w którym kod aplikacji jest dzielony na niezależne moduły funkcjonalne.

• lib/src/features/[nazwa_funkcjonalnosci]/presentation/: Zawiera kod UI (widżety i ekrany) dla danej funkcjonalności. Te widżety zależą od Providerów z tej lub innych funkcjonalności, używając ref.watch, ref.read itp.

• lib/src/features/[nazwa_funkcjonalnosci]/domain/: (wzorzec DDD) Modele danych i logika domenowa niezależna od implementacji.

• lib/src/features/[nazwa_funkcjonalnosci]/data/: Zawiera implementacje serwisów (np. klienta API, repozytorium bazy danych), które służą jako źródła danych dla warstwy application.

• lib/src/features/[nazwa_funkcjonalnosci]/providers/: Katalog przechowujący definicje Riverpod Providerów, które udostępniają stan, logikę z domain lub serwisy z data do warstwy presentation.

• lib/src/common/: Katalog dla elementów współdzielonych w całej aplikacji (widżety, helpery, globalne serwisy/proidery).

• lib/src/models/: Definicje globalnych modeli danych (np. klas danych, enumów).

• lib/src/services/: Abstrakcje lub implementacje globalnych serwisów (np. ApiService), które mogą być dostarczane poprzez Providerów z common/providers.

• test/: Katalog na pliki testowe. Struktura testów często odzwierciedla strukturę lib, aby łatwo znaleźć testy dla danego komponentu. Testowanie Providerów i Notifierów w izolacji jest kluczową zaletą Riverpod.

Aktualna struktura projektu:

lib/
├── main.dart                 # Główny plik aplikacji
├── src/
│   ├── features/
│   │   ├── account/         # Funkcjonalność zarządzania kontem
│   │   │   ├── data/
│   │   │   ├── domain/
│   │   │   └── presentation/
│   │   ├── auth/           # Funkcjonalność autentykacji
│   │   │   ├── data/
│   │   │   ├── domain/
│   │   │   └── presentation/
│   │   ├── explore/        # Funkcjonalność eksploracji
│   │   │   ├── data/
│   │   │   ├── domain/
│   │   │   └── presentation/
│   │   ├── user/           # Funkcjonalność użytkownika
│   │   │   ├── data/
│   │   │   ├── domain/
│   │   │   └── presentation/
│   │   └── user_chats/     # Funkcjonalność czatów użytkownika
│   │       ├── data/
│   │       ├── domain/
│   │       └── presentation/
│   ├── common/            # Współdzielone komponenty
│   ├── models/            # Globalne modele danych
│   └── services/          # Globalne serwisy
test/
├── account/
├── auth/
├── explore/
│ └── explore_test.dart
├── mocks.dart
└── mocks.mocks.dart

Każdy katalog funkcjonalności (account, auth, explore, user, user_chats) zawiera standardową strukturę z podziałem na warstwy:

• data/ - implementacje repozytoriów i źródeł danych
• domain/ - modele i logika biznesowa
• presentation/ - widoki i komponenty UI

Katalog zawierający testy zawiera strukturę która jest zorganizowana według funkcjonalności. Każdy moduł (feature) ma swój dedykowany podkatalog (np. auth, explore). Wewnątrz tych katalogów, pliki testowe mają nazwy opisujące testowany scenariusz. Taka płaska struktura unika dodatkowych zagnieżdżeń wewnątrz katalogów testowych.