Recherche organisation des dossiers


Feature-first

Exemple (approximatif) de structure feature-first, avec une séparation claire des responsabilités entre l’infrastructure technique, le métier et l’interface utilisateur. L’objectif est de garantir scalabilité, maintenabilité et faible couplage N.B. : ajout d’un dossier core afin d’empêcher shared de devenir un fourre-tout

Structure feature-first

core VS shared

Règle mentale simple:

Si je supprime ce dossier, est-ce que toute l’app s’écroule ?

  • Oui core
  • Non, mais je réécrirai du code shared

Est-ce que ça impose une façon de travailler aux features ?

  • Oui core
  • Non, c'est juste un outil pratique shared

pages vs features

✅ Ce que pages/* PEUT contenir

  • Récupération des params de route (router.query, getServerSideProps)
  • Choix du layout
  • Composition de composants
  • Passage de props
  • Décision “quel écran afficher”

❌ Ce que pages/* NE DOIT PAS contenir

  • Logique métier features
  • Hooks applicatifs (useCases) features
  • Mapping DTO FormType features
  • Orchestration complexe (workflows) features
  • Appels directs à React Query ou data-access features

Structure interne de features/my-feature

Un dossier feature est un module d’UI métier, indépendant du routing, qui expose des briques cohésives permettant de construire une ou plusieurs pages.

⚠️ Aucune dépendance au routing (pas de router.query) À passer en props depuis /pages

1. Screens

Point d’entrée UI métier.


features/orders/
├── order-overview/
├── create-order/

Contient :

  • Composition UI spécifique à une intention métier
  • Appel de hooks applicatifs (controllers)

2. Components (UI pure et réutilisable)


features/orders/
├── OrdersTable.tsx
├── OrderFilters.tsx

Contient :

  • JSX
  • props
  • callbacks
  • zéro React Query
  • zéro logique métier

❌ Ce qu’un dossier feature NE DOIT PAS contenir

  • Structure miroir de pages/ : car couplage au routing
  • Accès direct au router : le routing est une infra pages/
  • Logique de layout global : Hors feature
  • Providers globaux : Doivent être au niveau app

Gestion des layouts

Principe clé

Un layout est une décision de composition UI, pas métier.

Il décrit comment on affiche, pas _ce qu'_on fait.

Types de layouts et emplacement


1. Layout de page (route)

  • Encadre toute la page
  • Décidé par le routing 📍 Dans pages/
  • Global directement _app.tsx ou extraction de l'UI vers layouts/defaultLayout.tsx si le fichier devient trop gros et que les éléments UI polluent la lisibilité
  • Contextuel partagé shared/components/layouts/

2. Layout partagé (non métier)

  • Utilisé par plusieurs pages
  • Indépendant du domaine métier 📍 shared/components/layouts/ Exemples: EditorLayout, DashboardLayout, FullWidthLayout, CenteredLayout, ...

3. Sous-layout (layout partiel)


a) Métier
  • Structure une section d’UI liée à un domaine
  • Réutilisé dans plusieurs écrans 📍 features/*/
b) Générique
  • Structure UI réutilisable
  • Aucun lien métier 📍 shared/components/layouts/

À ne pas faire

  • ❌ Layout dans une feature s’il est décidé par la route
  • ❌ Layout métier dans shared/

Règle rapide

La route choisit le layout

La feature fournit l’UI métier Les sous-layouts métier restent dans la feature