Per 10 anni, l’ecosistema React si è spostato verso “Tutto lato client”. Abbiamo creato enormi applicazioni a pagina singola (SPA). Abbiamo recuperato i dati in “useEffect”. Abbiamo mostrato 10 spinner mentre le cascate si risolvevano. E abbiamo inviato 500KB di JavaScript a un utente con connessione 3G in Brasile, chiedendoci perché la “Conversione” fosse bassa.

React Server Components (RSC) è la correzione. Non è solo una caratteristica. Si tratta di un cambiamento architettonico fondamentale che riporta il centro di gravità al luogo a cui appartiene: il Datacenter.

Presso Maison Code Paris, abbiamo migrato enormi piattaforme di e-commerce su Next.js App Router. Il risultato? 40% in meno di JavaScript, Largest Contentful Paint (LCP) 2 volte più veloce e un’esperienza di sviluppo che sembra un imbroglio.

Perché Maison Code ne parla

In Maison Code Paris, agiamo come la coscienza architettonica dei nostri clienti. Spesso ereditiamo stack “moderni” costruiti senza una comprensione fondamentale della scala.

Discutiamo di questo argomento perché rappresenta un punto di svolta critico nella maturità ingegneristica. Implementarlo correttamente differenzia un MVP fragile da una piattaforma resiliente di livello aziendale.

Perché Maison Code scommette su RSC

Non inseguiamo ogni nuovo quadro. Inseguiamo il LTV del cliente. RSC è la prima architettura che allinea le prestazioni tecniche agli obiettivi aziendali:

• SEO: consegna HTML perfetta per i crawler (Google Bot adora RSC).
• Conversione: interazioni “Aggiungi al carrello” più veloci tramite l’interfaccia utente ottimistica.
• Sostenibilità: minore consumo della batteria sui dispositivi degli utenti scaricando i calcoli sul cloud. Formiamo tutti i nostri partner di agenzia su questo stack perché è il futuro del commercio ad alte prestazioni.

Il modello mentale: il server come albero dei componenti

Nel vecchio mondo (Pages Directory o Create-React-App), il server inviava HTML e il client “idratava” la funzionalità chiave. Nel mondo RSC, React viene eseguito sul server.

Quando un utente richiede “/product/123”:

1. Il server esegue il rendering di “ProductPage”.
2. Esegue await db.query().
3. Risolve i dati.
4. Serializza il risultato in un formato speciale (Flight Protocol).
5. Lo trasmette al browser.
6. Il browser esegue il rendering dell’interfaccia utente.

Fondamentale: Il codice per il componente server non lascia mai il server. Se importi “moment.js” (200 KB) in un componente server per formattare una data, l’utente ne scarica 0 KB. Vedono solo il testo “23 novembre 2025”.

Recupero dati: morte per useEffect

L’era dei “Loading Spinners” causati dalla logica lato client è finita. Non creiamo più percorsi API solo per alimentare il nostro frontend.

Il vecchio modello (Client FetH): “tsx // Componente client funzione Prodotto() { const [dati, setData] = useState(null); useEffect(() => { fetch(‘/api/product’).then(res => res.json()).then(setData); }, []);

if (!dati) restituisce ; return

**Il nuovo modello (RSC):**
"tsx
// Componente server
importa { db } da '@/lib/db';

esporta la funzione asincrona predefinita ProductPage() {
  // Accesso diretto al database. Sicuro. Veloce.
  dati const = attendono db.product.findFirst();
  
  return <div>{data.name}</div>;
}

Questo funziona sul backend. I dati aspettano l’utente, non viceversa.

Interattività: la direttiva “Use Client”.

Ma l’HTML statico è noioso. Abbiamo bisogno dei pulsanti “Aggiungi al carrello”. Reintroduciamo l’interattività utilizzando i Componenti client. Contrassegni un file con “use client”. Questo dice a Next.js: “Includi questo file nel bundle JavaScript”.

Modello di composizione: la strategia del “punto”. Non rendere l’intera pagina un componente client. Crea i componenti client foglie.

“tsx // Componente server (layout) esporta la funzione asincrona predefinita Pagina() { const prodotto = attendono db.product.findFirst();

ritorno (

## Azioni del server: mutazioni type-safe

Come inviamo i moduli? "Percorsi API"? "Axios"? "RESTO"?
No. **Azioni del server**.
Scriviamo una funzione che viene eseguita sul server e la passiamo come prop al modulo.

"tsx
// azioni.ts
'usa server'

esporta la funzione asincrona addToCart(formData: FormData) {
  const productId = formData.get('productId');
  attendono db.cart.create({ productId });
  // Dice alla cache locale di aggiornarsi
  revalidatePath('/carrello');
}

// Pulsante.tsx
importa { addToCart } da './actions';

funzione di esportazione AddToCartButton() {
  ritorno (
    <form azione={addToCart}>
      <button type="submit">Aggiungi</button>
    </forma>
  )
}

Funziona senza JavaScript abilitato (miglioramento progressivo). Se JS viene caricato, Next.js intercetta l’invio ed effettua effettivamente una chiamata API. Ma è come chiamare una funzione.

Interfaccia utente ottimistica: useOptimistic

Quando l’utente fa clic su “Aggiungi”, desideriamo un feedback immediato. Non vogliamo aspettare il viaggio di andata e ritorno del server. RSC introduce “useOptimistic”.

“tsx ‘usa client’ importa {useOptimistic} da ‘react’;

funzione di esportazione LikeButton({ likeCount, azione }) { const [optimisticLikes, addOptimisticLike] = useOptimistic( come Conte, (stato, nuovoMi piace) => stato + 1 );

ritorno ( <pulsante onClick={asincrono () => { addOptimisticLike(1); // Aggiornamento immediato dell’interfaccia utente attendere l’azione(); // Sincronizzazione in background del server }}> Mi piace: {optimisticLikes} ); }

## La gerarchia della memorizzazione nella cache

Next.js implementa la memorizzazione nella cache aggressiva per rendere veloci gli RSC.
Comprendere questa gerarchia è la parte più difficile della curva di apprendimento.

1. **Richiedi memoizzazione**: se chiami `getUser()` nel layout e `getUser()` nella pagina, Next.js lo deduplica. Viene eseguito solo una volta per richiesta.
2. **Cache dei dati**: il risultato di `fetch` viene archiviato sul disco del server. Persiste tra le richieste.
    `fetch('...', { successivo: { tag: ['prodotti'] } })`
3. **Cache completa del percorso**: l'HTML renderizzato + il payload del volo viene memorizzato nella cache in fase di creazione (generazione del sito statico).
4. **Cache del router**: il browser memorizza nella cache le pagine visitate per 30 secondi per la navigazione istantanea avanti/indietro.

**Invalidazione**:
Quando aggiorni un prodotto, devi chiamare `revalidateTag('products')` nella tua azione del server. Ciò elimina istantaneamente il livello 2 e il livello 3.

## 10. Prerendering parziale (PPR)

Statico (SSG) è veloce ma obsoleto. Dynamic (SSR) è fresco ma lento.
Next.js 14 ha introdotto **PPR**.
È il modello "Hole in the Donut".
La shell (intestazione, piè di pagina, barra laterale) viene pre-renderizzata in fase di creazione.
Il "Prezzo del prodotto" è il buco. Si carica dinamicamente.
L'utente ottiene l'HTML istantaneo (The Shell) e le parti dinamiche vengono trasmesse in streaming dopo 100 ms.
Ciò impedisce lo "Schermo bianco della morte" durante le query del database.

## 11. Confini di streaming e suspense

RSC divide la pagina in blocchi.
"return <Suspense fallback={<Skeleton />}><SlowComponent /></Suspense>"
Il server invia l'intestazione HTTP "Transfer-Encoding: Chunked".
1. Blocco 1: `<html>...<nav>... <Skeleton>`
2. (DB termina)
3. Parte 2: `<script>sostituisci(Skeleton, RealContent)</script>`
Questo **Time To First Byte (TTFB)** è fondamentale per la SEO e le prestazioni percepite.

## 13. RSC vs Architettura dell'isola (Astro)

Astro ha reso popolari le "Isole" (HTML statico + piccoli buchi di interattività).
RSC è simile ma diverso.
* **Astro**: spedisci 0 JS per impostazione predefinita. Idratare esplicitamente `<Counter client:load />`.
* **RSC**: spedisci 0 JS per impostazione predefinita. I componenti Hydrate contrassegnati con "usa client".
La differenza è il **Router**.
Next.js ha un router lato client (sensazione SPA). Astro utilizza la navigazione multipagina (aspetto classico).
Per l'e-commerce (dove è fondamentale mantenere lo stato del carrello durante i caricamenti delle pagine), il modello Next.js/RSC è generalmente superiore al modello MPA puro.

## 14. La gestione dello Stato in un mondo RSC

Dove va Redux?
Luogo inesistente. Non ne hai bisogno.
Se lo stato è "Dati server" (Prodotti, Profilo utente), risiede nel componente server (recuperato per richiesta).
Se lo stato è "UI State" (Modal Open, Accordion espanso), si trova in "useState" all'interno di una foglia del componente client.
Utilizziamo solo **Global State** (Zusstand/Context) per dati cliente veramente globali: **Cart** e **Auth Token**.
Tutto il resto (il 90% dei vecchi negozi Redux) viene eliminato.

## 15. Conclusione

I componenti React Server rappresentano il più grande cambiamento nello sviluppo frontend dall'introduzione di AJAX.
Ci permettono di costruire "MPA (App Multi-Page) con l'anima delle SPA".
Otteniamo il SEO, le prestazioni e la semplicità del rendering del server.
Otteniamo la ricca interattività di React.

Per l’e-commerce su larga scala, dove ogni millisecondo di latenza è correlato ai ricavi, RSC è l’unica architettura praticabile per i prossimi 5 anni.


<hr style="margin: 1rem 0" />

### Migrazione a Next.js?
Sei bloccato su un'app Create-React lenta?


**[Architetta la tua migrazione](/services/tech)** con RSC.
**[Assumi i nostri architetti](/contact)**.