Best Practices und Code-Organisation in React

Dieses Kapitel fasst zusammen, WARUM unser Projekt so strukturiert ist, wie es ist – als bewusste Rückschau über beide Serien hinweg ("React für Einsteiger" + "React für Profis"), damit Sie die Prinzipien dahinter auf EIGENE, neue Projekte übertragen können.

Die Ordnerstruktur im Rückblick: warum nach TYP, nicht nach Feature

Unser Projekt organisiert Dateien nach TECHNISCHEM TYP: components/, pages/, hooks/, store/, api/. Die Alternative – "feature-basierte" Struktur (features/cart/ mit ALLEM Warenkorb-Bezogenen darin: Komponente, Slice, Tests, API-Aufrufe) – skaliert oft besser für SEHR große Teams/Apps, ist aber für ein Projekt dieser Größe unnötige Vorab-Komplexität.

Struktur	Trade-off
Nach Typ (unser Projekt)	Einfach zu verstehen, wenig Overhead, gut für kleine bis mittlere Projekte. Bei sehr vielen Features werden Ordner wie `components/` irgendwann unübersichtlich groß.
Nach Feature	Alles Zusammengehörige liegt beieinander, Löschen eines Features = einen Ordner löschen. Mehr initiale Struktur-Entscheidungen nötig, für kleine Projekte oft übertrieben.

Tipp: Faustregel: bei UNTER ca. 15-20 Komponenten nach Typ organisieren (wie hier), DANACH auf Feature-basiert umstellen, wenn components/ zu einer unübersichtlichen, langen Liste wird. Eine vorzeitige Feature-Struktur für eine kleine App ist genauso ein Over-Engineering-Fehler wie eine fehlende Struktur für eine riesige App.

Wann eine Komponente aufteilen?

ProductListPage ist mittlerweile eine unserer größten Dateien (Laden, Fehler-Handling, Suche, Pagination, Redux-Dispatch – alles in EINER Funktion). Ein häufiges Warnsignal: wenn Sie beim Lesen einer Komponente scrollen müssen, um den GESAMTEN JSX-Rückgabewert zu sehen, ist das ein Kandidat für Aufteilung. Mögliche nächste Schritte für ProductListPage (bewusst NICHT in diesem Tutorial umgesetzt, als Übung für Sie): die Such-/Filter-Logik in einen Custom Hook useProductSearch auslagern, die Pagination-UI in eine eigene <Pagination />-Komponente.

Namenskonventionen, die wir konsequent durchgehalten haben

Komponenten: PascalCase-Dateiname = Komponentenname (ProductCard.jsx exportiert ProductCard) – beim Import ist SOFORT klar, was die Datei enthält.
Custom Hooks: IMMER mit use-Präfix (useDocumentTitle, useAuthStore) – React's ESLint-Regeln (eslint-plugin-react-hooks) erkennen Hooks NUR an diesem Namensmuster und können sonst "Rules of Hooks"-Verstöße nicht zuverlässig prüfen.
Event-Handler: handle...-Präfix für lokale Funktionen (handleFavoriteClick), on...-Präfix für Props, die selbst Callback-Funktionen sind (onAddToCart) – die Unterscheidung macht beim Lesen sofort klar, WER die Funktion aufruft.
Boolean-Variablen/Props: is.../has...-Präfix (isFavorite, isPending, hasError wäre konsequenter als unser error-State gewesen, der eigentlich die Fehlermeldung selbst hält, keinen Boolean).

Automatisierung: ESLint und Prettier

Vite-Projekte bringen ESLint meist schon vorkonfiguriert mit (npm create vite fragt danach). Ergänzen Sie eslint-plugin-react-hooks, falls noch nicht vorhanden – es fängt genau die Fehler ab, die wir in "React für Einsteiger" Kapitel 8-12 manuell erklärt haben (fehlende useEffect-Abhängigkeiten, Hooks in Bedingungen aufgerufen). Prettier formatiert Code automatisch beim Speichern – Formatierungsdiskussionen in Code-Reviews werden dadurch komplett überflüssig.

npm install --save-dev eslint-plugin-react-hooks prettier

Ein Muster, das wir konsequent wiederholt haben

Fällt Ihnen das wiederkehrende loading/error/Daten-Dreiklang auf? ProductListPage (Kapitel 23 aus "React für Einsteiger"), SearchDemoPage-ähnliche Muster, sogar unsere Test-Suite aus dem letzten Kapitel prüft implizit dieses Muster. KONSISTENZ über ein Projekt hinweg ist selbst eine Form von Qualität – ein neuer Teamkollege, der EIN Beispiel dieses Musters versteht, versteht sofort ALLE anderen Stellen, die es verwenden.

Tipp: Der wichtigste Best-Practice-Ratschlag zum Schluss: KONSISTENZ schlägt "Perfektion". Ein Projekt, das ein leicht suboptimales Muster ÜBERALL gleich anwendet, ist wartbarer als eines, das für jedes Feature die "theoretisch beste" individuelle Lösung wählt. Entscheiden Sie sich im Team für Konventionen (Ordnerstruktur, Namensgebung, Fehlerbehandlung) und halten Sie sich konsequent daran – wichtiger als WELCHE Konvention exakt gewählt wird.