_Assistant_Lead_Tech/knowledge/frontend/risques/react-native.md

Frontend — Risques & vigilance : React Native

Extrait de la base de connaissance Lead_tech. Voir knowledge/frontend/risques/README.md pour l'index complet.

---

Focus ring sur TextInput React Native

Risques

• React Native n'a pas de pseudo-classe :focus — le focus visuel ne s'implémente pas en CSS
• Tâche souvent marquée [x] sans vérification effective du state focused

Symptômes

• TextInput sans indication visuelle de focus → accessibilité et UX dégradées
• Story marquée done mais aucun handler onFocus/onBlur présent dans le composant

Bonnes pratiques / mitigations

const [focused, setFocused] = useState(false);

<TextInput
  onFocus={() => setFocused(true)}
  onBlur={() => setFocused(false)}
  style={[styles.input, focused && styles.inputFocused]}
/>

• Règle de review : toute story "focus ring" doit présenter un state focused + handlers + style conditionnel
• Contexte technique : React Native — app-alexandrie, 25-03-2026

---

ScrollView.contentInset — propriété iOS-only

Risques

• contentInset n'est pas supporté sur Android — le contenu passe sous la bottom tab bar sans aucune erreur de build
• Pattern fréquent quand on copie un pattern iOS existant dans un nouvel écran

Symptômes

• Sur iOS : rendu correct avec padding bottom
• Sur Android : contenu masqué sous la bottom tab bar

Bonnes pratiques / mitigations

// ❌ Anti-pattern — iOS-only, cassé sur Android
<ScrollView contentInset={{ bottom: insets.bottom }}>

// ✅ Pattern correct — cross-platform
<ScrollView contentContainerStyle={{ paddingBottom: insets.bottom }}>

• Règle de review : auditer systématiquement tout ScrollView avec contentInset dans les PR concernant des écrans avec bottom navigation
• Contexte technique : React Native / react-native-safe-area-context — app-alexandrie, 25-03-2026

---

fetch sans vérification response.ok — erreurs non-2xx silencieuses

Risques

• Sans vérification de response.ok, les réponses 404/500 retournent le JSON d'erreur sans exception → le code appelant ne sait pas que la requête a échoué
• En cas de proxy qui retourne du HTML sur erreur (ex : 502 Bad Gateway), response.json() throw une SyntaxError cryptique plutôt qu'une erreur métier

Symptômes

• Store qui reçoit { error: { code, message } } comme si c'était une réponse valide
• SyntaxError: JSON Parse error inexpliquée lors des erreurs réseau

Bonnes pratiques / mitigations

const response = await fetch(url, options);
const json = (await response.json()) as T;
if (!response.ok) {
  throw json; // throw le body d'erreur structuré pour un catch cohérent
}
return json;

• Règle : tout fetch dans le http-client doit vérifier response.ok avant de retourner le JSON parsé
• Contexte technique : React Native / fetch — app-alexandrie review 5.2, 27-03-2026