Dieses Kapitel fasst zusammen, WARUM unser Projekt so strukturiert ist, wie es ist – als bewusste Rückschau über beide Serien hinweg ("React Native für Einsteiger" + "React Native für Profis"), mit besonderem Fokus auf die Unterschiede zu "React für Profis" Kapitel 45 (Web).

Die Ordnerstruktur im Rückblick

GENAU dieselbe Typ-basierte Struktur wie im Web-Pendant: screens/ (entspricht pages/ im Web), components/, store/, api/, types/. EIN Unterschied fällt sofort auf: kein hooks/-Ordner mehr – wir haben ihn in Kapitel 2 entfernt, weil useCart.js vollständig durch store/cartStore.ts ersetzt wurde. Ein guter Reminder: Ordnerstrukturen sind kein Selbstzweck, sie sollten sich mit der tatsächlichen Architektur mitentwickeln, nicht als Altlast bestehen bleiben.

Namenskonventionen: identisch, mit einer RN-Ergänzung

Alle Konventionen aus "React für Profis" Kapitel 45 gelten unverändert (PascalCase-Komponenten, use-Präfix für Hooks, handle/on-Präfix für Event-Handler/Callback-Props). RN-spezifisch dazu: Screen-Komponenten tragen KONSEQUENT das Suffix Screen (ProductListScreen, CartScreen), NICHT Page wie im Web-Pendant – eine kleine, aber in der RN-Community fest etablierte Konvention, die sofort signalisiert "das ist ein Navigations-Ziel", nicht "das ist eine wiederverwendbare Komponente".

Wann eine Screen-Datei aufteilen?

ProductListScreen ist nach 5 Kapiteln (Badge, Favoriten, Performance-Tuning) eine unserer größeren Dateien geworden. GENAU wie in "React für Profis" Kapitel 45 empfohlen: die Such-/Filter-Logik ließe sich in einen Custom Hook auslagern, die Header-Badge-Logik in eine eigene Komponente. Ein RN-spezifischer zusätzlicher Kandidat: getItemLayout/keyExtractor/renderItem-Funktionen einer komplexen FlatList lassen sich oft sinnvoll AUSSERHALB der Komponentenfunktion definieren (als eigenständige, benannte Funktionen statt Inline-Definitionen), was gleichzeitig Lesbarkeit UND Performance verbessert (stabile Funktionsreferenzen, siehe Kapitel 5).

Plattform-spezifischer Code: ein RN-eigenes Organisationsmuster

Ein Muster, das im Web-Pendant keine Entsprechung hat: Dateien mit .ios.tsx/.android.tsx-Endungen werden von Metro AUTOMATISCH plattformspezifisch aufgelöst, ohne Platform.select() (siehe "React Native Referenz", Thema "Plattform- und Geräteinformationen") explizit im Code schreiben zu müssen:

components/
  ShareButton.ios.tsx      # wird auf iOS automatisch geladen
  ShareButton.android.tsx  # wird auf Android automatisch geladen
  # Beide exportieren dieselbe Komponente unter demselben Namen -
  # der Rest der App importiert einfach "./ShareButton", ohne die Plattform zu kennen

Nutzen Sie dieses Muster, wenn sich die Implementierung ZWISCHEN Plattformen so stark unterscheidet, dass Platform.select() innerhalb EINER Datei unübersichtlich würde – für kleinere Unterschiede (wie unser elevation/shadow*-Beispiel aus der "React Native Referenz"-Serie) bleibt Platform.select() die einfachere Wahl.

ESLint für React Native

npx expo install --dev eslint eslint-config-expo

eslint-config-expo ist das RN-spezifische Äquivalent zu eslint-plugin-react-hooks aus "React für Profis" Kapitel 45 – enthält dieselben Hooks-Regeln PLUS zusätzliche, Expo-/RN-spezifische Regeln (z. B. Warnungen bei veralteten Image-Props, die durch expo-image-Äquivalente ersetzt werden sollten).