React
TypeScript o JavaScript per la UI: cosa cambia davvero
TypeScript non rende automaticamente migliore una UI. Serve dove i confini sono ambigui: props, varianti, token e dati che arrivano da un catalogo. Ecco dove conviene e dove no.
In sintesi
- Il valore di TypeScript è nei confini, non nel numero di tipi scritti.
- Una API di componenti tipizzata bene riduce le varianti impossibili più di qualsiasi test visivo.
- JavaScript resta ragionevole per script, prototipi e file di configurazione.
La domanda “TypeScript o JavaScript?” nasce quasi sempre da un progetto già avviato. La risposta utile è: dove il tipo previene un errore che il test non vede? Il resto è preferenza.
Dove TypeScript paga
| Confine | Errore che previene | Esempio |
|---|---|---|
| Props di un componente | Valori non previsti | `variant: "ghost" | "solid"` |
| Dati da API | Campi assenti o rinominati | Risposta del catalogo |
| Token di design | Nomi inesistenti | `--ui-surface` vs `--ui-surf` |
| Registry item | File e dipendenze mancanti | Installazione incompleta |
| Eventi e ref | Tipo sbagliato a runtime | `HTMLButtonElement` |
Dove TypeScript costa
- Componenti polimorfici: i generics diventano difficili da leggere prima di essere utili.
- Migrazioni parziali: i `any` impliciti spostano il problema senza risolverlo.
- Tempo di build e configurazione, se il progetto è piccolo.
- Tipi scritti a mano per dati che cambiano spesso: meglio generarli.
Una API tipizzata che vale la pena
type Variant = "solid" | "outline" | "ghost";
type Size = "sm" | "md" | "lg";
type ButtonProps = {
variant?: Variant;
size?: Size;
loading?: boolean;
} & React.ButtonHTMLAttributes;
export function Button({ variant = "solid", size = "md", ...props }: ButtonProps) {
return ;
}Questo tipo impedisce tre errori che nessun test visivo intercetta: una variante inesistente, una taglia inventata, un attributo che il bottone non supporta.
La migrazione incrementale che funziona
- Attiva `strict` dal primo giorno sui file nuovi, non su tutto il progetto.
- Tipizza prima i confini: props pubbliche, risposte API, funzioni esportate.
- Genera i tipi dai dati reali invece di scriverli a mano.
- Non convertire i file solo per aggiungere un tipo: converti quando tocchi il file per un motivo.
Il test che decide
Prendi il componente più usato del progetto e tipizzalo per intero. Se il tempo speso trova almeno un errore reale, la migrazione ha senso. Se non trova nulla, il problema era altrove.
Il catalogo EneUI espone componenti e blocchi con metadati strutturati (31 ottobre 2026: 111.985 componenti, 1.556 blocchi): sono dati che valgono la pena di essere tipizzati perché descrivono ciò che installi.
Domande frequenti
TypeScript è obbligatorio con React?
No. React funziona in JavaScript. TypeScript aggiunge controlli sui confini, non requisiti di runtime.
Quanto tempo richiede una migrazione?
Dipende da quanti `any` e quanti confini ci sono. Una migrazione incrementale per file è più sostenibile di una conversione totale.
I tipi rallentano lo sviluppo?
Scriverli richiede tempo; leggerli riduce le ipotesi. Il saldo dipende dalla dimensione del progetto e dalla stabilità delle API.
Meglio `type` o `interface`?
Per le props `type` è sufficiente. `interface` è utile quando vuoi estendere. La coerenza conta più della scelta.
Posso usare TypeScript solo nei componenti nuovi?
Sì, purché il confine sia esplicito. I file misti senza `strict` producono falsa sicurezza.