mirror of
https://github.com/MaksTinyWorkshop/_Assistant_Lead_Tech
synced 2026-04-06 21:41:42 +02:00
91 lines
3.0 KiB
Markdown
91 lines
3.0 KiB
Markdown
# 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
|