Règles React
Statut
Document de règles projet — version initiale.
Objectif
Encadrer les frontends React, Next.js et Vite pour garder des interfaces simples, performantes et maintenables.
Règles strictes
- Ne pas réimplémenter les règles métier sensibles côté frontend.
- Ne pas exposer de secret dans les variables publiques.
- Ne pas mélanger état global et état local sans nécessité.
- Ne pas créer un composant générique avant d'avoir un usage répété clair.
- Ne pas charger des données inutiles sur mobile.
- Ne pas ignorer les états erreur, vide et chargement.
Principes
- Composants petits et lisibles.
- Données chargées au plus près du besoin.
- État local par défaut.
- Réutilisation quand elle simplifie.
- Accessibilité intégrée.
- Performance mobile surveillée.
Next.js
Pour dmv-public :
- privilégier les capacités App Router quand elles simplifient ;
- garder les pages publiques optimisées SEO ;
- limiter le JavaScript client inutile ;
- documenter les composants interactifs ;
- protéger les données personnalisées.
React/Vite
Pour dmv_backoffice :
- privilégier la clarté des pages d'administration ;
- paginer ou filtrer les listes importantes ;
- ne pas surcharger les dashboards ;
- isoler les appels API ou Supabase dans des services dédiés.
Data fetching
- Utiliser SWR ou pattern équivalent quand pertinent.
- Gérer loading, error, empty, success.
- Éviter les appels multiples redondants.
- Ne pas dépendre durablement d'accès directs Supabase pour règles métier sensibles.
Anti-patterns
- Composant de 500 lignes avec logique, UI et appels réseau.
- État global utilisé pour tout.
- Données métier mutées côté client sans validation backend.
- Copie de composants entre apps sans convention.
- UI impossible à utiliser sans souris.
État actuel vs cible
| Sujet | État actuel | Cible |
|---|---|---|
| Public | Next.js, React 19, SWR, Tailwind. | PWA locale performante. |
| Backoffice | React/Vite, Router, Recharts. | Admin efficace et lisible. |
| Supabase JS | Visible côté frontends. | Rationalisation progressive via API. |
Points à clarifier
- Structure officielle des composants.
- Design system partagé.
- Stratégie de tests frontend.
- Migration progressive des accès data.