Aller au contenu principal

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 actuelCible
PublicNext.js, React 19, SWR, Tailwind.PWA locale performante.
BackofficeReact/Vite, Router, Recharts.Admin efficace et lisible.
Supabase JSVisible 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.