Deployment di Applicazioni React

Introduzione

Il deployment di un’applicazione React consiste nel preparare il codice per la produzione e pubblicarlo su un server accessibile agli utenti. Questo processo include ottimizzazione del codice, build per produzione e configurazione del server per gestire correttamente il routing client-side. Questo articolo esplora come funziona il processo di deployment, le tecniche di ottimizzazione come il lazy loading e la configurazione necessaria per applicazioni single-page.

Processo di Deployment

Il deployment di un’applicazione React segue questi passaggi: test del codice, ottimizzazione, build per produzione e upload su un server.

Test e Ottimizzazione

Prima del deployment, è importante testare l’applicazione e identificare opportunità di ottimizzazione. Il lazy loading è una tecnica comune per ridurre il tempo di caricamento iniziale.

Build per Produzione

Il codice sviluppato non è quello che viene deployato. Durante lo sviluppo si usa codice leggibile con JSX e altre funzionalità che devono essere trasformate. Il build process produce un bundle ottimizzato e minificato pronto per la produzione.

Upload e Configurazione

Il bundle prodotto viene caricato su un hosting provider. Per applicazioni React single-page, serve un static site host che serve file HTML, CSS e JavaScript senza eseguire codice lato server.

Lazy Loading

Il lazy loading carica componenti solo quando necessari, invece di caricare tutto il codice all’inizio. Questo riduce il tempo di caricamento iniziale.

Come Funziona il Caricamento Standard

Senza lazy loading, tutti gli import vengono risolti prima di mostrare qualcosa sullo schermo:

1
import BlogPage from './pages/Blog';
2
import { blogLoader } from './pages/Blog';
3

4
const router = createBrowserRouter([
5
  {
6
    path: '/blog',
7
    element: <BlogPage />,
8
    loader: blogLoader
9
  }
10
]);

Quando l’applicazione viene servita, tutti i file importati devono essere caricati prima che qualcosa venga visualizzato. In applicazioni complesse con molte route e componenti, questo può rallentare il caricamento iniziale.

Implementazione del Lazy Loading

Per caricare un componente solo quando necessario, si usa React.lazy e import():

1
import { lazy, Suspense } from 'react';
2

3
// Caricamento lazy del componente
4
const BlogPage = lazy(() => import('./pages/Blog'));
5

6
// Caricamento lazy del loader
7
const router = createBrowserRouter([
8
  {
9
    path: '/blog',
10
    element: (
11
      <Suspense fallback={<p>Loading...</p>}>
12
        <BlogPage />
13
      </Suspense>
14
    ),
15
    loader: () => {
16
      return import('./pages/Blog').then(module => {
17
        return module.blogLoader();
18
      });
19
    }
20
  }
21
]);

React.lazy accetta una funzione che chiama import() dinamicamente. import() come funzione restituisce una Promise che si risolve con il modulo quando il codice viene caricato.

Suspense mostra un fallback mentre il componente viene caricato. Senza Suspense, si verificherebbe un errore perché lazy restituisce una Promise, non un componente valido.

1
{
2
  path: '/posts/:postId',
3
  element: (
4
    <Suspense fallback={<p>Loading...</p>}>
5
      <PostPage />
6
    </Suspense>
7
  ),
8
  loader: ({ params }) => {
9
    return import('./pages/Post').then(module => {
10
      return module.postLoader({ params });
11
    });
12
  }
13
}

Verifica del Lazy Loading

Per verificare che il lazy loading funzioni, si apre la Network tab nelle DevTools del browser. Quando si naviga a una route caricata lazy, appare una richiesta per un file JavaScript aggiuntivo che viene scaricato dinamicamente.

Build per Produzione

Il build process trasforma e ottimizza il codice per la produzione. Con Create React App, si esegue:

npm run build

Questo script:

• Trasforma il JSX in JavaScript standard
• Minifica il codice
• Ottimizza le dimensioni del bundle
• Separa il codice in chunk per il lazy loading
• Produce file pronti per il deployment

Il risultato è una cartella build contenente:

• index.html: file HTML principale
• static/: cartella con JavaScript, CSS e altri asset ottimizzati

Il contenuto della cartella build è quello che viene deployato sul server.

1
build/
2
  ├── index.html
3
  └── static/
4
      ├── js/
5
      │   ├── main.[hash].js      # Codice principale
6
      │   ├── [chunk].[hash].js   # Chunk lazy-loaded
7
      │   └── ...
8
      ├── css/
9
      │   └── main.[hash].css
10
      └── media/
11
          └── ...

Deployment su Static Site Host

Le applicazioni React single-page sono statiche: consistono solo di file HTML, CSS e JavaScript che vengono eseguiti nel browser. Non richiedono un server che esegue codice.

Molti provider offrono hosting per siti statici: Firebase Hosting, Netlify, Vercel, GitHub Pages, AWS S3, ecc.

Esempio: Firebase Hosting

Firebase Hosting è un esempio di provider per siti statici. Il processo di setup include:

1. Installazione degli strumenti Firebase:

npm install -g firebase-tools

2. Login:

firebase login

3. Inizializzazione del progetto:

firebase init

Durante l’inizializzazione, si seleziona:

• Hosting come feature
• Il progetto Firebase esistente o se ne crea uno nuovo
• La cartella build come directory da deployare
• Yes per configurare come single-page application

4. Deploy:

firebase deploy

Questo comando carica i file dalla cartella build sui server Firebase e fornisce un URL pubblico per accedere al sito.

Configurazione per Client-Side Routing

Un aspetto critico del deployment è la configurazione del server per gestire correttamente il routing client-side.

Client-Side vs Server-Side Routing

Con server-side routing, ogni path corrisponde a un file o una risorsa sul server. Quando si richiede /blog, il server cerca un file o una route corrispondente.

Con client-side routing (React Router), il routing viene gestito dal JavaScript nel browser. Il server deve sempre servire lo stesso file HTML indipendentemente dal path richiesto.

Il Problema

Quando un utente inserisce direttamente un URL come example.com/blog o ricarica la pagina su quella route:

1. Il browser invia una richiesta HTTP al server per /blog
2. Per default, il server cerca un file o una route corrispondente a /blog
3. Non trovando nulla, il server restituisce un 404

Il server dovrebbe invece restituire sempre index.html, permettendo a React Router di gestire il routing nel browser.

La Soluzione

Il server deve essere configurato per servire sempre index.html per qualsiasi path richiesto. Questo è chiamato fallback a index.html o configurazione per single-page application.

Con Firebase Hosting, rispondere “Yes” alla domanda “Configure as a single-page app?” configura automaticamente questa regola. La configurazione viene salvata in firebase.json:

1
{
2
  "hosting": {
3
    "public": "build",
4
    "ignore": [
5
      "firebase.json",
6
      "**/.*",
7
      "**/node_modules/**"
8
    ],
9
    "rewrites": [
10
      {
11
        "source": "**",
12
        "destination": "/index.html"
13
      }
14
    ]
15
  }
16
}

La regola rewrites dice al server di servire /index.html per qualsiasi richiesta (**).

1
[[redirects]]
2
  from = "/*"
3
  to = "/index.html"
4
  status = 200

1
location / {
2
  try_files $uri $uri/ /index.html;
3
}

1
<IfModule mod_rewrite.c>
2
  RewriteEngine On
3
  RewriteBase /
4
  RewriteRule ^index\.html$ - [L]
5
  RewriteCond %{REQUEST_FILENAME} !-f
6
  RewriteCond %{REQUEST_FILENAME} !-d
7
  RewriteRule . /index.html [L]
8
</IfModule>

Riepilogo

Il deployment di un’applicazione React include test, ottimizzazione, build e upload su un server. Il lazy loading riduce il caricamento iniziale caricando componenti solo quando necessari usando React.lazy e Suspense.

Il build process trasforma e ottimizza il codice, producendo una cartella build con file pronti per la produzione. Le applicazioni React single-page sono statiche e richiedono solo un static site host.

La configurazione del server è critica per il client-side routing: il server deve servire sempre index.html per qualsiasi path, permettendo a React Router di gestire il routing nel browser. Senza questa configurazione, le route dirette o i refresh della pagina risultano in errori 404.