React Compiler elimina useMemo e useCallback in React 19. Ecco come attivarlo in Next.js App Router, i suoi limiti e i problemi da evitare nel 2026.
React Compiler memoizza automaticamente i vostri componenti e i vostri valori, senza che dobbiate scrivere nemmeno un useMemo o useCallback. Concretamente: il compilatore analizza il vostro codice al momento della build e inserisce da solo la memoizzazione dove ha senso, il che dovrebbe ridurre drasticamente il numero di re-render inutili in un'app React 19.
Ma funziona davvero in un'app Next.js App Router in produzione, oggi? Abbiamo approfondito la questione, testato su un progetto reale, e ecco quello che ne abbiamo ricavato: attivazione, limiti e casi in cui è meglio non toccarlo.
Che cos'è react compiler, concretamente
React Compiler è uno strumento che viene eseguito al momento della build e trasforma il vostro codice sorgente per iniettarvi automaticamente memoizzazione. Nessuna nuova API da imparare, nessun hook supplementare. Legge i vostri componenti così come li scrivete oggi, con props, state e dipendenze, e deduce da solo dove un useMemo o un useCallback manuale sarebbe stato necessario.
Prima del compilatore, uno sviluppatore doveva indovinare quali calcoli costosi meritassero di essere memoizzati e elencare manualmente le dipendenze di ogni hook. Indovinare, è la parola giusta. Abbiamo tutti già dimenticato una dipendenza in un array di useCallback e debuggato uno state scaduto per due ore.
Il compilatore toglie questa responsabilità umana. Applica una regola semplice: se un componente rispetta le regole di React (nessuna mutazione diretta delle props, nessun effetto collaterale nel render), può essere analizzato staticamente e memoizzato automaticamente.
Quello che cambia davvero per il vostro team: il codice diventa più breve, più leggibile, e soprattutto più difficile da rompere per errore. Un'osservazione che spesso sorprende i team che migrano: rimuovere manualmente tutti gli useMemo esistenti a volte migliora le prestazioni, perché il compilatore fa un lavoro più fine di quello che un umano affrettato avrebbe scritto manualmente.
Quello che il compilatore non fa
Non sostituisce la logica di business. Non indovina neanche le vostre intenzioni di business: se il vostro componente ha un bug di logica, il compilatore non lo correggerà mai. Ottimizza il render, punto.
Come attivarlo in un'app next.js app router
L'attivazione avviene a livello di build, tramite un plugin Babel dedicato configurato nel vostro progetto. Su un progetto Next.js App Router esistente, la procedura tipica è più o meno così:
- Installare il plugin React Compiler come dipendenza di sviluppo.
- Attivarlo nella configurazione di Next.js (
next.config.js), in genere tramite un'opzione sperimentale finché la funzionalità continua a maturare. - Lanciare una build completa e confrontare il bundle prima/dopo: il compilatore aggiunge codice di memoizzazione, il peso del bundle può aumentare leggermente.
- Testare in profondità i componenti con state complesso: form multi-step, liste filtrabili, tutto quello che dipende da re-render precisi.
- Rimuovere progressivamente i
useMemo/useCallbackmanuali esistenti, non tutti in una volta.
Il punto 5 è quello che tutti sbagliano. Abbiamo voglia di ripulire il codice d'un colpo dopo l'attivazione. Cattiva idea. Il compilatore coesiste molto bene con il codice già memoizzato manualmente, quindi niente obbliga a riscrivere tutto il giorno dell'attivazione.
I problemi che abbiamo incontrato testando il compilatore
Qui bisogna essere onesti: non va magicamente bene dappertutto.
Primo problema: i componenti che violano discretamente le regole di React - mutazione diretta di un oggetto passato in props, effetto collaterale nascosto in un render condizionale - semplicemente non sono ottimizzati dal compilatore. Peggio, possono produrre comportamenti incoerenti tra la modalità dev e la modalità compilata, il che rende il debug più difficile di prima.
Secondo problema: le librerie di terze parti. Se la vostra app dipende da componenti esterni che non rispettano queste regole, il compilatore semplicemente li ignora. Non avete quindi un guadagno uniforme su tutta l'app, ma un guadagno concentrato sul vostro codice.
Terzo problema, più sottile: su un progetto in cui gli sviluppatori avevano già fatto un lavoro rigoroso di memoizzazione manuale, il guadagno di performance misurato era scarso. Il compilatore brilla soprattutto dove il team non aveva il tempo o la disciplina di memoizzare correttamente - il che è il caso della maggior parte dei progetti, siamo sinceri.
Questo approccio ha un limite chiaro: non funziona bene se la vostra base di codice contiene molti componenti di classe legacy, o codice che manipola il DOM direttamente al di fuori del ciclo di render di React. In questo caso, migrare verso componenti funzionali standard prima di attivare il compilatore rimane un prerequisito obbligatorio.
Tabella comparativa: memoizzazione manuale vs react compiler
| Criterio | Memoizzazione manuale (useMemo/useCallback) | React Compiler |
|---|---|---|
| Sforzo dello sviluppatore | Elevato, ogni caso da identificare e codificare | Basso, automatico alla build |
| Rischio di errore | Dipendenze dimenticate, bug di state scaduto | Ridotto, ma dipende dal rispetto delle regole di React |
| Leggibilità del codice | Appesantita da hook ovunque | Codice sorgente più vicino al render naturale |
| Copertura | Mirata dove lo sviluppatore ha pensato di aggiungerla | Uniforme su ogni componente conforme |
| Compatibilità librerie terze | Non interessato | Non si applica ai componenti esterni non conformi |
| Maturità nel 2026 | Standard da anni | Disponibile ma ancora contrassegnato come sperimentale su alcune config |
Conclusione
Tre cose da ricordare prima di attivare React Compiler sul vostro prossimo progetto Next.js. Prima, non sostituisce il rigore: il codice che viola le regole di React rimane un codice che il compilatore non può salvare. Secondo, il guadagno reale dipende dallo stato attuale della vostra base di codice: più la vostra memoizzazione manuale era disordinata, più il guadagno sarà visibile. Infine, la migrazione deve essere progressiva: attivare, testare, poi ripulire il codice esistente, mai il contrario.
Se il vostro team sta già lavorando a una migrazione Next.js più ampia, abbiamo parlato proprio della fine della vita di Next.js 15 e del piano di migrazione verso la versione 16: il compilatore è uno dei cantieri da integrare in questa roadmap piuttosto che trattarlo come un progetto separato. E se l'argomento del build e del compilatore in generale vi interessa, abbiamo anche approfondito quello che cambia il compilatore TypeScript nativo in Go per i vostri tempi di build.
Avete bisogno di un audit prima di migrare la vostra app verso React Compiler? Contattate fstck.co per guardare insieme se la vostra base di codice è pronta.
Domande frequenti
React compiler funziona con i componenti di classe react?
No. Il compilatore analizza solo i componenti funzionali e gli hook. Una base di codice con molti componenti di classe legacy deve prima essere migrata verso componenti funzionali prima di poter beneficiare del compilatore.
Bisogna rimuovere tutti gli usememo e usecallback esistenti dopo aver attivato il compilatore?
No, e non è nemmeno consigliabile farlo tutto in una volta. Il compilatore coesiste senza problemi con il codice già memoizzato manualmente. È meglio attivare, misurare, poi ripulire progressivamente componente per componente.
React compiler rallenta il tempo di build su un progetto next.js grande?
Sì, l'analisi statica aggiunge un costo al build, generalmente moderato su progetti di dimensioni medie. Su monorepo molto grandi, questo costo merita di essere misurato prima della messa in produzione, confrontando i tempi di build prima/dopo sulla vostra CI.
Si può usare react compiler con next.js pages router, o solo con app router?
Il compilatore agisce a livello del build Babel, indipendentemente dal router utilizzato. Funziona quindi in teoria anche con Pages Router, ma la maggior parte dei feedback di esperienza e della documentazione si concentra su progetti App Router nel 2026.
Come sapere se il mio codice rispetta le regole di react necessarie al compilatore?
Un plugin ESLint dedicato consente di rilevare le violazioni prima ancora di attivare il compilatore al build. Questo è il primo step consigliato: lanciare il linter su tutta la base di codice, correggere le violazioni segnalate, poi solo allora attivare il compilatore.
