mirror of
https://github.com/MaksTinyWorkshop/_Assistant_Lead_Tech
synced 2026-04-27 14:58:16 +02:00
Backend: 21 entrées (general, prisma, contracts, auth, patterns) Frontend: 9 entrées (navigation, tests, general, performance, patterns) Workflow: 5 entrées (story-tracking) Nouveau fichier: backend/patterns/general.md 95_a_capitaliser.md purgé. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2.6 KiB
2.6 KiB
Frontend — Risques & vigilance : Performance
Extrait de la base de connaissance Lead_tech. Voir
knowledge/frontend/risques/README.mdpour l'index complet.
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
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.memone peut pas éviter le re-render
Symptômes
const handleToggle = useCallback((id: string) => { ... }, []); // stable ✓
// Mais au render :
<ItemCard onToggle={() => handleToggle(item.id)} />
// ↑ nouvelle closure à chaque render → memo inutile
Bonnes pratiques / mitigations
-
useCallbackn'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 :
- Passer les données en props et laisser l'enfant appeler le handler avec ses propres props
- Accepter que
memone soit pas protégé et supprimer leuseCallbackinutile
-
Ne pas laisser un
useCallback"pour faire bien" si son effet réel est nul -
Contexte technique : React — app-template-resto 22-03-2026
Fetch sans timeout pour ressources lourdes
Risques
fetch()sans timeout pour charger des blobs/fichiers volumineux (PDF, images) laisse l'utilisateur attendre indéfiniment sur connexion dégradée- Critique sur mobile avec connexion instable ; faux sentiment de freeze pour l'utilisateur
Symptômes
fetch(url)sansAbortController+ timeout pour des blobs/fichiers volumineux- Spinner infini sans message d'erreur
Bonnes pratiques / mitigations
-
Utiliser
AbortControlleravecsetTimeout(15s recommandé) -
Attraper
AbortErroret afficher un message explicite à l'utilisateur -
Signal review : tout
fetchde blob/fichier sansAbortControllerest suspect -
Contexte technique : frontend / mobile — RL799_V2 06-04-2026