0Pricing
Frontend Academy · Lezione

Struttura delle cartelle basata sulle funzionalità

Organizzare il codice per dominio funzionale anziché per tipo, affiancare test, stili e componenti e imporre i confini con eslint-plugin-boundaries

Struttura delle cartelle basata sulle funzionalità è una lezione Frontend Academy gratuita su CoddyKit. Questa è la lezione 4 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento Frontend Academy, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso Frontend Academy include 4 lezioni in totale.

Due modi per organizzare il codice

È possibile raggruppare il codice per tipo (components/, hooks/, services/, types/) oppure per funzionalità (auth/, checkout/, dashboard/, ciascuna con i propri components, hooks e così via). L'organizzazione per funzionalità è più adatta alle applicazioni medio-grandi.

Per tipo: la trappola predefinita

La struttura classica dei tutorial su React raggruppa tutto per tipo. Cresce male: ogni modifica a un file coinvolge più cartelle non correlate e, per «trovare tutto il codice di checkout», bisogna eseguire grep nell'intero albero.

// Type-based (avoid for large apps):
src/
  components/
    Button.tsx
    LoginForm.tsx
    CartItem.tsx
  hooks/
    useAuth.ts
    useCart.ts
  services/
    auth.ts
    cart.ts
  types/
    User.ts
    CartItem.ts

Struttura per funzionalità

Raggruppare in un'unica cartella tutto ciò che riguarda una funzionalità. È facile da trovare, facile da eliminare e facile da comprendere.

src/
  features/
    auth/
      LoginForm.tsx
      SignupForm.tsx
      useAuth.ts
      auth.service.ts
      auth.types.ts
      auth.test.tsx
    cart/
      CartItem.tsx
      CartSummary.tsx
      useCart.ts
      cart.service.ts
      cart.types.ts
  shared/
    components/
      Button.tsx
    hooks/
      useDebounce.ts

Co-localizzazione all'interno di una funzionalità

Una cartella di funzionalità contiene componenti, hook, servizi, tipi e test: tutto il codice necessario per quel dominio. Un nuovo sviluppatore vuole capire auth? Apre auth/. Vuole eliminare auth? Elimina la cartella.

Condiviso o specifico della funzionalità

Il codice usato da 2 o più funzionalità viene spostato in shared/ (o lib/). Il codice usato da una sola funzionalità rimane al suo interno. Evitare di pensare «potrebbe essere riutilizzabile in futuro»: attendere il secondo utilizzo prima di estrarlo.

Regole dei confini tra funzionalità

Le funzionalità non dovrebbero importarsi direttamente a vicenda. Se due funzionalità devono condividere del codice, la parte condivisa va spostata in shared/. Se devono coordinarsi, usare eventi o uno store condiviso a livello di applicazione.

Applicare i confini con ESLint

Usare eslint-plugin-boundaries o eslint-plugin-import per imporre la regola: le funzionalità possono importare da shared, ma non l'una dall'altra.

// .eslintrc.json
{
  "plugins": ["boundaries"],
  "settings": {
    "boundaries/elements": [
      { "type": "feature", "pattern": "src/features/*" },
      { "type": "shared",  "pattern": "src/shared/*" }
    ]
  },
  "rules": {
    "boundaries/element-types": ["error", {
      "default": "disallow",
      "rules": [
        { "from": "feature", "allow": ["shared"] },
        { "from": "shared",  "allow": ["shared"] }
      ]
    }]
  }
}

API pubblica per ogni funzionalità

Ogni funzionalità esporta un'API pubblica tramite features/auth/index.ts. Il resto del codice importa da '@/features/auth', non da percorsi profondi. In questo modo è possibile riorganizzare gli interni senza interrompere i consumer.

// features/auth/index.ts
export { LoginForm } from './LoginForm';
export { useAuth } from './useAuth';
export type { User, AuthState } from './auth.types';

// Consumers:
import { LoginForm, useAuth } from '@/features/auth';
// NOT: import { LoginForm } from '@/features/auth/LoginForm';

Annidare le sottofunzionalità

Le funzionalità grandi possono avere sottocartelle: dashboard/widgets/, dashboard/charts/. Evitare di superare 2 o 3 livelli di annidamento: la ricerca diventa difficoltosa.

Dove collocare le route

Le pagine e le route possono trovarsi in una cartella di primo livello pages/ o routes/. Sono sottili: recuperano componenti e hook dalle funzionalità e li compongono.

src/
  pages/
    Dashboard.page.tsx   // composes Dashboard widgets from features/dashboard/
    Cart.page.tsx        // composes from features/cart/
  features/
  shared/

Migrare un'applicazione esistente

Iniziare solo dalle nuove funzionalità: inserire il nuovo codice in features/. Non eseguire il refactoring di tutto in una volta. Quando si modificano i vecchi file, spostarli gradualmente. Le regole sui confini di ESLint prevengono regressioni nella nuova struttura.

Quando l'organizzazione per tipo funziona ancora

Per applicazioni molto piccole (meno di 30 componenti) o librerie, l'organizzazione per tipo va bene. Usare quella per funzionalità non appena sono presenti domini di business distinti (auth, checkout, billing, settings).

Verifica rapida

Qual è il principale vantaggio organizzativo di raggruppare il codice per funzionalità invece che per tipo di file?

Riepilogo: struttura per funzionalità

features/ contiene il codice specifico dei domini; shared/ contiene le utility condivise tra le funzionalità. Ogni funzionalità esporta un index.ts pubblico. Le funzionalità non si importano a vicenda: importano solo da shared. Applicare i vincoli con eslint-plugin-boundaries. Pagine e route compongono le funzionalità. Migrare gradualmente. L'organizzazione per tipo va bene per le applicazioni piccole.

Domande Frequenti

La lezione «Struttura delle cartelle basata sulle funzionalità» è gratuita?

Sì — il testo completo di «Struttura delle cartelle basata sulle funzionalità» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso Frontend Academy, passa a CoddyKit PRO. Il corso Frontend Academy include 4 lezioni in totale.

Cosa imparerò in «Struttura delle cartelle basata sulle funzionalità»?

Organizzare il codice per dominio funzionale anziché per tipo, affiancare test, stili e componenti e imporre i confini con eslint-plugin-boundaries Eserciti Frontend Academy con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.

Ho bisogno di esperienza per iniziare Frontend Academy?

Non è richiesta alcuna esperienza precedente. Frontend Academy su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 4 di 4.

Quanto tempo richiede la lezione «Struttura delle cartelle basata sulle funzionalità»?

La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.

Posso scrivere ed eseguire codice in questa lezione Frontend Academy?

Sì. Ogni lezione Frontend Academy include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.

Tutte le lezioni di questo corso

  1. Atomic Design: atomi, molecole e organismi
  2. Configurare un monorepo con Turborepo
  3. Micro-frontend: Module Federation
  4. Struttura delle cartelle basata sulle funzionalità
← Torna a Frontend Academy