# Frontend — Risques & vigilance : React Native

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

---

<a id="risque-focus-ring-textinput"></a>
## 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

```typescript
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

---

<a id="risque-contentinset-ios-only"></a>
## `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

```typescript
// ❌ 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

---

<a id="risque-fetch-sans-response-ok"></a>
## `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

```typescript
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