React-Native-Interviewfragen

Was ist der Unterschied zwischen Props und State in React Native?

Props sind nur lesbare Daten, die von einer Elternkomponente übergeben werden, und gehören dem, der sie übergibt; State gehört der Komponente selbst und ändert sich über die Zeit via useState oder useReducer. Eine Komponente, die zweimal dieselben Props ohne State-Änderung erhält, sollte dieselbe Ausgabe rendern — genau das macht Props vorhersagbar. Setter über Props nach unten zu reichen ("State nach oben heben") ist der Standardweg, damit ein Kind eine State-Änderung auslösen kann, die es selbst nicht besitzt.

Was ist JSX, und wozu wird es tatsächlich kompiliert?

JSX ist syntaktischer Zucker für React.createElement-Aufrufe — <View style={styles.box}>{text}</View> wird zu einem verschachtelten Baum von Element-Objekten, nicht zu echten DOM-Knoten, weil es auf native keine DOM gibt. Babels Transform wandelt die Tags in Funktionsaufrufe um, bevor der JS überhaupt läuft — JSX ist also eine Build-Time-Annehmlichkeit, kein Runtime-Feature. In React Native beschreiben diese Element-Objekte am Ende eine native View-Hierarchie statt HTML.

Was machen `useState` und `useEffect`, und wann läuft der Effekt?

useState gibt einer Komponente ein Stück State und einen Setter, der bei Aufruf einen Re-Render auslöst; useEffect führt einen Seiteneffekt aus, nachdem der Render committed wurde, und läuft nur erneut, wenn sich etwas im Dependency-Array geändert hat. Eine vergessene Dependency ist die häufigste Ursache für stale Closures — der Effekt referenziert weiterhin den Wert aus dem Render, in dem er erstellt wurde. Ein leeres Dependency-Array heißt "einmal beim Mount ausführen", kein Array heißt "nach jedem Render ausführen".

Wie funktioniert Styling in React Native, und warum verhält sich Flexbox anders als im Web?

Es gibt kein CSS — Styles sind JS-Objekte, erstellt mit StyleSheet.create und unter der Haube auf native View-Properties gemappt. Flexbox bleibt die Layout-Engine, aber flexDirection ist standardmäßig column statt row, es gibt keine CSS-Kaskade, und Einheiten sind einheitenlose density-independent Pixel statt px/em/rem. Prozentuale Breiten, flex: 1 zum Ausfüllen des verbleibenden Platzes und justifyContent/alignItems zur Ausrichtung decken die meisten realen Layouts ab.

Wie funktioniert Navigation mit React Navigation, und was bringt Deep Linking zusätzlich?

React Navigation modelliert die App als Baum von Navigatoren — Stack, Tab, Drawer —, jeder Screen wird unter einem Namen registriert, und navigation.navigate('Screen', params) wechselt zwischen ihnen, während ein History-Stack für die Zurück-Geste erhalten bleibt. Deep Linking mappt ein externes URL-Schema oder einen Universal Link auf einen bestimmten Screen mit Parametern, sodass eine Push-Benachrichtigung oder ein Web-Link den Nutzer direkt in, sagen wir, einen Bestelldetails-Screen bringt statt auf den App-Startbildschirm. Es richtig hinzubekommen bedeutet, sowohl einen Cold Start (App läuft nicht) als auch eine Warm-Resume-Situation über einen Link zu behandeln.

Was ist die Bridge, und wie unterscheidet sie sich von JSI und der New Architecture?

In der alten Architektur teilen sich JS und nativer Code keinen Speicher — sie kommunizieren über die Bridge, eine asynchrone, gebatchte, JSON-serialisierte Message-Queue, wodurch jeder native Call Serialisierungskosten und Latenz mit sich bringt. JSI (JavaScript Interface) ersetzt das durch direkte C++-Bindings, sodass JS Referenzen auf native Objekte halten und deren Methoden synchron aufrufen kann, ganz ohne Serialisierung. Die New Architecture baut auf JSI auf: TurboModules ersetzen native Module, und Fabric ersetzt den alten UI-Manager — beide können direkt mit nativem Code sprechen, statt über die Bridge zu queuen.

Wie hältst du eine lange `FlatList` davon ab, zu ruckeln?

Gib jedem Item einen stabilen keyExtractor, memoize die Row-Komponente mit React.memo, damit ein Re-Render des Parents nicht jede Zeile neu rendert, und vermeide inline Funktionen und Objekt-Literale in renderItem, weil eine neue Referenz bei jedem Render die Memoization zunichtemacht. getItemLayout überspringt einen Messdurchlauf, wenn die Zeilenhöhe fix ist, und windowSize/initialNumToRender/removeClippedSubviews tauschen Speicher gegen Scroll-Flüssigkeit. Für sehr große oder komplexe Listen löst FlashList von Shopify dasselbe Problem mit weniger Tuning-Aufwand.

Was sind die realen Unterschiede zwischen dem Bau für iOS und Android in React Native?

Safe Areas, Keyboard-Verhalten und Schatten-Styling (shadow*-Props auf iOS vs. elevation auf Android) weichen so weit voneinander ab, dass pixelgenaue Parität plattformspezifischen Code über Platform.select oder .ios.js/.android.js-Dateiendungen braucht. Permissions, Push-Notification-Setup und Background-Task-Limits folgen den jeweils eigenen Regeln der Plattform — Androids Background-Execution-Limits und Apples strengeres App-Store-Review sind unterschiedliche Constraints, nicht nur unterschiedliche APIs. Ein für eine Plattform geschriebenes natives Modul braucht ein echtes Gegenstück in Swift/Objective-C und Kotlin/Java, bevor es auf beiden funktioniert.

Wie kommt ein Release tatsächlich raus — was haben Metro, OTA-Updates und das Store-Review miteinander zu tun?

Metro bundlet und serviert den JS während der Entwicklung und packt ihn für den Release ins App-Binary — es ist nicht Teil dessen, was Nutzer bekommen, sondern nur das Build-Tool. OTA-Update-Dienste wie CodePush oder Expo Updates pushen ein neues JS-Bundle direkt auf installierte Apps ohne App-Store- oder Play-Store-Review, was schnell für Bugfixes ist, aber ausdrücklich verboten für alles, was nativen Code ändert oder über das hinausgeht, was der Store als "nur Content" betrachtet. Native Änderungen — ein neues natives Modul, eine Permission, ein SDK-Bump — brauchen immer einen vollständigen Build und eine neue Store-Einreichung, weshalb ein Team auf zwei Geschwindigkeiten fährt: OTA für reine JS-Fixes, Store-Releases für alles Native.