Rozbudowane narzędzia IDE typu Visual Studio mają tę zaletę (albo wadę - o tym potem :)), że udostępniają szablony projektów, wprowadzając pewną standaryzację do tego, jak zorganizowane są pliki projektu. Sztandarowy przykład to szablon ASP.NET MVC z Visual Studio, który domyślnie tworzy foldery typu Controllers czy Views, będące domyślnym miejscem do umieszczenia - odpowiednio - kontrolerów i widoków.
W świecie frontendowym sytuacja jest dużo bardziej \"rozmyta\". Tworząc aplikacje Reactowe w zasadzie narzędziami pracy są konsola oraz edytor (Visual Studio Code :heart:). Ale nawet skorzystanie z CLI, które \"scaffolduje\" projekt (np. create-react-app) nie wprowadza (narzuca?) struktury folderów, która by była umożliwiała \"ustandaryzowany\" układ folderów nawet, gdy aplikacja się rozrośnie. create-react-app w zasadzie \"standaryzuje\" tylko istnienie folderu src. Przyznacie, że to trochę mało. Gdzie umieszczać testy? Gdzie umieścić komponenty, a gdzie moduły \"niewizualne\" (np. serwisy kontaktujące się z zewnętrznym API)? Każdy deweloper jakoś odpowiada na te pytania, ale to skutkuje tym, że w ramach zespołu trudniej utrzymać spójność, a szerzej - jeśli każdy projekt przyjmuje inną filozofię organizacji plików, to trudniej się w tym połapać.\nJeśli ktoś korzysta z Reacta wraz z Reduxem, to mógł spotkać się z propozycją, aby zgrupować komponenty w dwóch folderach: containers i components. W tym pierwszym powinny znaleźć się komponenty \"wyższego rzędu\", tj. te, które są \"podpięte\" pod Reduxa, w drugim folderze - pozostałe. Takie rozwiązanie wydaje mi się jednak niepraktyczne - zmiana komponentu z Redux-agnostic na Redux-wise nie powinna oznaczać konieczności przenosin pliku do innego folderu. Inna sprawa, że to nie jest szablon/standard, tylko rekomendacja.
Wobec braku standaryzacji organizacji plików i folderów w świecie frontendowym, mogę i ja zaproponować własne rozwiązanie. :) Stosuję je ostatnio w projektach, które - chyba można tak powiedzieć - osiągnęły już rozmiar midi. Zasada jest następująca:
\n\n\nGrupuj pliki według funkcjonalności, a nie według technicznego podobieństwa.
\n
Oznacza to tyle - na przekór np. struktury szablonu projektu ASP.NET MVC - że nie mamy folderu typu views, zbierającego widoki, albo reducers, do którego, jak do worka, wrzucamy wszystkie reducery. Moim zdaniem lepiej grupować pliki według fragmentów aplikacji. Przykładowo, jeśli mamy \"podstronę\" do administracji (użytkownicy, role itp.), to niech wszystko, co jest potrzebne do tej części systemu niech będzie w folderze administration. Oczywiście dalej można to pokroić na dalsze podfoldery, czy to dalej według kolejnych \"podsystemów\" (users, roles), czy już bardziej technicznie.\nCo nam daje takie rozwiązanie? Otóż, moim zdaniem, aplikacja przestaje być jedną wielką kulą błota, gdzie mieszamy style CSS, komponenty Reactowe, testy itp., ale raczej wprowadzamy hierarchię: aplikacja składa się z modułów (np. ów moduł administracyjny, reprezentowany przez folder administration), a te moduły składają się z technicznych \"cegieł\" - np. plików z komponentami Reactowymi. Dodatkowo, niejako gratis, dostajemy jeszcze możliwość stosowania krótszych nazw plików (nie trzeba powtarzać wszędzie prefiksu, bo nadrzędny folder może mówić, jaki tu jest obszar zaimplementowany) oraz potencjalne łatwiejsze wydzielenie podprojektów i skorzystanie z narzędzi typu Lerna.\nInnymi słowy - niech struktura plików w projekcie będzie sugerowała, że mamy do czyniania z \"modularnym monolitem\". ;)
W praktyce pewnie nie warto wydzielać takie foldery-moduły jako pierwszy krok po stworzeniu projektu za pomocą create-react-app: jesli aplikacja jest na wczesnej fazie rozwoju, to nie musimy się wiązać konkretnym podziałem. Chyba lepiej najpierw zacząć szybko, kosztem lekkiego bałaganu, a w odpowiednim momencie, gdy już wyklaruje się, z jakimi obszarami mamy do czynienia, wprowadzić taki podział na foldery-moduły.