Refonte Structure

knowledge/frontend/risques/performance.md

@@ -0,0 +1,57 @@
+# Frontend — Risques & vigilance : Performance
+
+> Extrait de la base de connaissance Lead_tech. Voir `knowledge/frontend/risques/README.md` pour l'index complet.
+
+---
+
+<a id="risque-performances-sur-renders"></a>
+## Performances : sur-renders + bundle non maîtrisé
+
+### Risques
+
+- App lente sur mobile
+- Bundle qui grossit sans contrôle
+- Chargements inutiles (images, libs)
+
+### Symptômes
+
+- Input lag
+- Temps de chargement qui dérive à chaque feature
+- Requêtes réseaux inutiles
+
+### Bonnes pratiques / mitigations
+
+- Lazy loading routes/features
+- Mesurer (au minimum) : temps de chargement + re-renders critiques
+- Politique images (formats, tailles, lazy)
+- Audit régulier des dépendances
+
+---
+
+<a id="risque-usecallback-inutile-inline"></a>
+## `useCallback` inutile quand le callback est wrappé en inline au render
+
+### Risques
+
+- Le handler stable est re-wrappé dans une arrow inline lors du passage en prop → nouvelle référence à chaque render → `React.memo` ne peut pas éviter le re-render
+
+### Symptômes
+
+```tsx
+const handleToggle = useCallback((id: string) => { ... }, []); // stable ✓
+
+// Mais au render :
+<ItemCard onToggle={() => handleToggle(item.id)} />
+//                 ↑ nouvelle closure à chaque render → memo inutile
+```
+
+### Bonnes pratiques / mitigations
+
+- `useCallback` n'a de valeur que si le callback est passé **directement** en prop, sans re-wrapping
+- Si la signature doit capturer des variables de boucle, deux options :
+  1. Passer les données en props et laisser l'enfant appeler le handler avec ses propres props
+  2. Accepter que `memo` ne soit pas protégé et supprimer le `useCallback` inutile
+- Ne pas laisser un `useCallback` "pour faire bien" si son effet réel est nul
+
+- Contexte technique : React — app-template-resto 22-03-2026
+