App Router Next.js: cosa ho imparato davvero
La migrazione da Pages Router ad App Router è stata più grande di quanto pensassi. Non è solo un cambio di struttura cartelle — è un cambio di mentalità.
Il cambio più impattante non è la struttura delle cartelle ma il modello di rendering. Con App Router, ogni componente è un Server Component per default. Questo significa che il codice gira sul server, può accedere direttamente al database o al filesystem, e non spedisce JavaScript al client. La prima volta che ho capito questo ho riscritto metà delle mie applicazioni.
Il punto di confusione più comune: quando usare 'use client'. La risposta è più semplice di quanto sembri: solo quando il componente usa hooks React (useState, useEffect, useContext) o event listeners del browser. Tutto il resto può essere server. Ho iniziato a pensarci al contrario: tutto è server finché non devo renderlo client.
Il gotcha che mi ha sorpreso di più è il comportamento del caching. In App Router, le fetch sono cacciate di default in modo aggressivo. Questo è ottimo per le performance ma può causare dati stale in sviluppo. Ho imparato a essere esplicito: { cache: 'no-store' } per dati dinamici, { next: { revalidate: 3600 } } per dati semi-statici. Non aspettarsi che Next.js indovini l'intenzione.