Deprecazione di Create React App

14 febbraio 2025 di Matt Carroll e Ricky Hanlon

Quando abbiamo rilasciato Create React App nel 2016, non c’era un modo chiaro per costruire una nuova app React.

Per creare un’app React, dovevi installare un mucchio di strumenti e collegarli insieme per supportare funzionalità di base come JSX, linting e hot reloading. Era molto difficile farlo correttamente, quindi la community ha creato boilerplate per setup comuni. Tuttavia, i boilerplate erano difficili da aggiornare e la frammentazione rendeva difficile per React rilasciare nuove funzionalità.

Create React App ha risolto questi problemi combinando diversi strumenti in una singola configurazione raccomandata. Questo ha permesso alle app un modo semplice per aggiornarsi alle nuove funzionalità del tooling e ha permesso al team React di distribuire cambiamenti di tooling non banali (supporto Fast Refresh, regole lint React Hooks) al pubblico più ampio possibile.

Questo modello è diventato così popolare che oggi esiste un’intera categoria di strumenti che funzionano in questo modo.

Deprecazione di Create React App

Sebbene Create React App renda facile iniziare, ci sono diverse limitazioni che rendono difficile costruire app di produzione ad alte performance. In linea di principio, potremmo risolvere questi problemi evolvendo essenzialmente Create React App in un framework.

Tuttavia, poiché Create React App attualmente non ha maintainer attivi e ci sono molti framework esistenti che risolvono già questi problemi, abbiamo deciso di deprecare Create React App.

A partire da oggi, se installi una nuova app, vedrai un avviso di deprecazione:

Abbiamo anche aggiunto un avviso di deprecazione al sito web e al repo GitHub di Create React App. Create React App continuerà a funzionare in modalità manutenzione, e abbiamo pubblicato una nuova versione di Create React App compatibile con React 19.

Come migrare a un framework

Raccomandiamo di creare nuove app React con un framework. Tutti i framework che raccomandiamo supportano client-side rendering (CSR) e single-page app (SPA), e possono essere distribuiti su un CDN o un servizio di hosting statico senza un server.

Per le app esistenti, queste guide ti aiuteranno a migrare a una SPA solo client:

• Guida di migrazione Create React App di Next.js
• Guida all’adozione framework di React Router.
• Guida di migrazione Expo webpack a Expo Router

Come migrare a un build tool

Se la tua app ha vincoli insoliti, preferisci risolvere questi problemi costruendo il tuo framework, o vuoi semplicemente imparare come funziona React da zero, puoi creare la tua configurazione personalizzata con React usando Vite, Parcel o Rsbuild.

Per le app esistenti, queste guide ti aiuteranno a migrare a un build tool:

• Guida di migrazione Create React App con Vite
• Guida di migrazione Create React App con Parcel
• Guida di migrazione Create React App con Rsbuild

Per aiutarti a iniziare con Vite, Parcel o Rsbuild, abbiamo aggiunto nuova documentazione per Building a React App from Scratch.

Continua a leggere per saperne di più sulle limitazioni dei build tool e perché raccomandiamo i framework.

Limitazioni dei build tool

Create React App e build tool simili rendono facile iniziare a costruire un’app React. Dopo aver eseguito npx create-react-app my-app, ottieni un’app React completamente configurata con un development server, linting e una build di produzione.

Ad esempio, se stai costruendo uno strumento admin interno, puoi iniziare con una landing page:

export default function App() {
  return (
    <div>
      <h1>Welcome to the Admin Tool!</h1>
    </div>
  )
}

Questo ti consente di iniziare immediatamente a scrivere codice in React con funzionalità come JSX, regole lint predefinite e un bundler da usare sia in development che in produzione. Tuttavia, questo setup manca degli strumenti necessari per costruire una vera app di produzione.

La maggior parte delle app di produzione ha bisogno di soluzioni a problemi come routing, data fetching e code splitting.

Routing

Create React App non include una soluzione di routing specifica. Se stai iniziando, un’opzione è usare useState per passare tra le route. Ma farlo significa che non puoi condividere link alla tua app — ogni link andrebbe alla stessa pagina — e strutturare la tua app diventa difficile nel tempo:

import {useState} from 'react';

import Home from './Home';
import Dashboard from './Dashboard';

export default function App() {
  // ❌ Routing in state does not create URLs
  const [route, setRoute] = useState('home');
  return (
    <div>
      {route === 'home' && <Home />}
      {route === 'dashboard' && <Dashboard />}
    </div>
  )
}

Ecco perché la maggior parte delle app che usano Create React App aggiunge il routing con una libreria di routing come React Router o Tanstack Router. Con una libreria di routing, puoi aggiungere route aggiuntive all’app, che fornisce opinioni sulla struttura della tua app e ti consente di iniziare a condividere link alle route. Ad esempio, con React Router puoi definire le route:

import {RouterProvider, createBrowserRouter} from 'react-router';

import Home from './Home';
import Dashboard from './Dashboard';

// ✅ Each route has it's own URL
const router = createBrowserRouter([
  {path: '/', element: <Home />},
  {path: '/dashboard', element: <Dashboard />}
]);

export default function App() {
  return (
    <RouterProvider value={router} />
  )
}

Con questo cambiamento, puoi condividere un link a /dashboard e l’app navigherà alla pagina dashboard. Una volta che hai una libreria di routing, puoi aggiungere funzionalità aggiuntive come route annidate, route guards e transizioni di route, che sono difficili da implementare senza una libreria di routing.

Qui c’è un tradeoff: la libreria di routing aggiunge complessità all’app, ma aggiunge anche funzionalità difficili da implementare senza di essa.

Recupero dati

Un altro problema comune in Create React App è il data fetching. Create React App non include una soluzione di data fetching specifica. Se stai iniziando, un’opzione comune è usare fetch in un Effetto per caricare i dati.

Ma farlo significa che i dati vengono recuperati dopo che il componente renderizza, il che può causare network waterfall. I network waterfall sono causati dal recuperare dati quando la tua app renderizza invece che in parallelo mentre il codice si sta scaricando:

export default function Dashboard() {
  const [data, setData] = useState(null);

  // ❌ Fetching data in a component causes network waterfalls
  useEffect(() => {
    fetch('/api/data')
      .then(response => response.json())
      .then(data => setData(data));
  }, []);

  return (
    <div>
      {data.map(item => <div key={item.id}>{item.name}</div>)}
    </div>
  )
}

Recuperare dati in un Effetto significa che l’utente deve aspettare più a lungo per vedere il contenuto, anche se i dati avrebbero potuto essere recuperati prima. Per risolvere, puoi usare una libreria di data fetching come TanStack Query, SWR, Apollo o Relay che forniscono opzioni per prefetchare i dati così la richiesta inizia prima che il componente renderizzi.

Queste librerie funzionano al meglio quando integrate con il pattern “loader” del tuo routing per specificare le dipendenze dati a livello di route, il che consente al router di ottimizzare i tuoi fetch di dati:

export async function loader() {
  const response = await fetch(`/api/data`);
  const data = await response.json();
  return data;
}

// ✅ Fetching data in parallel while the code is downloading
export default function Dashboard({loaderData}) {
  return (
    <div>
      {loaderData.map(item => <div key={item.id}>{item.name}</div>)}
    </div>
  )
}

Al caricamento iniziale, il router può recuperare i dati immediatamente prima che la route venga renderizzata. Mentre l’utente naviga nell’app, il router è in grado di recuperare sia i dati che la route contemporaneamente, parallelizzando i fetch. Questo riduce il tempo necessario per vedere il contenuto sullo schermo e può migliorare l’esperienza utente.

Tuttavia, questo richiede di configurare correttamente i loader nella tua app e scambia complessità per performance.

Suddivisione del codice

Un altro problema comune in Create React App è il code splitting. Create React App non include una soluzione di code splitting specifica. Se stai iniziando, potresti non considerare affatto il code splitting.

Ciò significa che la tua app viene spedita come un singolo bundle:

- bundle.js    75kb

Ma per performance ideali, dovresti “dividere” il tuo codice in bundle separati così l’utente deve scaricare solo ciò di cui ha bisogno. Questo riduce il tempo che l’utente deve aspettare per caricare la tua app, scaricando solo il codice necessario per vedere la pagina in cui si trova.

- core.js      25kb
- home.js      25kb
- dashboard.js 25kb

Un modo per fare code-splitting è con React.lazy. Tuttavia, ciò significa che il codice non viene recuperato finché il componente non renderizza, il che può causare network waterfall. Una soluzione più ottimale è usare una funzionalità del router che recupera il codice in parallelo mentre il codice si sta scaricando. Ad esempio, React Router fornisce un’opzione lazy per specificare che una route deve essere code split e ottimizzare quando viene caricata:

import Home from './Home';
import Dashboard from './Dashboard';

// ✅ Routes are downloaded before rendering
const router = createBrowserRouter([
  {path: '/', lazy: () => import('./Home')},
  {path: '/dashboard', lazy: () => import('Dashboard')}
]);

Un code-splitting ottimizzato è difficile da fare bene, ed è facile commettere errori che possono far scaricare all’utente più codice del necessario. Funziona al meglio quando integrato con le soluzioni di router e data loading per massimizzare la cache, parallelizzare i fetch e supportare pattern “import on interaction”.

E altro…

Questi sono solo alcuni esempi delle limitazioni di Create React App.

Una volta integrato routing, data-fetching e code splitting, devi anche considerare pending state, interruzioni di navigazione, messaggi di errore all’utente e revalidazione dei dati. Ci sono intere categorie di problemi che gli utenti devono risolvere come:

Tutti questi lavorano insieme per creare la loading sequence più ottimale.

Risolvere ciascuno di questi problemi individualmente in Create React App può essere difficile poiché ogni problema è interconnesso con gli altri e può richiedere competenze approfondite in aree che gli utenti potrebbero non conoscere. Per risolvere questi problemi, gli utenti finiscono per costruire soluzioni su misura sopra Create React App, che era esattamente il problema che Create React App cercava di risolvere.

Perché raccomandiamo i framework

Sebbene potresti risolvere tutti questi pezzi da solo in un build tool come Create React App, Vite o Parcel, è difficile farlo bene. Proprio come quando Create React App stesso integrava diversi build tool insieme, hai bisogno di uno strumento che integri tutte queste funzionalità insieme per offrire la migliore esperienza agli utenti.

Questa categoria di strumenti che integra build tool, rendering, routing, data fetching e code splitting è nota come “framework” — o se preferisci chiamare React stesso un framework, potresti chiamarli “metaframework”.

I framework impongono alcune opinioni sulla strutturazione della tua app per fornire un’esperienza utente molto migliore, nello stesso modo in cui i build tool impongono alcune opinioni per rendere il tooling più facile. Ecco perché abbiamo iniziato a raccomandare framework come Next.js, React Router ed Expo per i nuovi progetti.

I framework forniscono la stessa esperienza di getting started di Create React App, ma forniscono anche soluzioni ai problemi che gli utenti devono comunque risolvere nelle app di produzione reali.

Grazie a Dan Abramov per aver creato Create React App, e a Joe Haddad, Ian Schmitz, Brody McKee e molti altri per aver mantenuto Create React App nel corso degli anni. Grazie a Brooks Lybrand, Dan Abramov, Devon Govett, Eli White, Jack Herrington, Joe Savona, Lauren Tan, Lee Robinson, Mark Erikson, Ryan Florence, Sophie Alpert, Tanner Linsley e Theo Browne per la revisione e il feedback su questo post.