Poche domande su TypeScript provocano tanto dibattito quanto Interfaccia TypeScript e tipo. Molti articoli elencano le differenze che erano importanti nelle versioni precedenti ma che ora non sono aggiornate. Quindi, invece di ripetere le affermazioni, le abbiamo testate.

Abbiamo scritto un file esercitando ciascuna differenza e lo abbiamo controllato con TypeScript 5.6.3 in modalità rigorosa. Gli errori del compilatore citati di seguito provengono da quell’esecuzione. Il comportamento può cambiare tra le versioni, quindi verifica rispetto alla versione TypeScript utilizzata dal tuo progetto. Se non conosci il linguaggio, inizia con il nostro tutorial TypeScript per principianti.

La risposta breve

Un interface descrive la forma di un oggetto e può essere esteso o riaperto. Un alias type dà un nome a qualsiasi tipo, inclusi oggetti, unioni, tuple e tipi di funzione. Laddove entrambi possono funzionare, la differenza è principalmente nello stile.

Dove sono gli stessi

Queste due dichiarazioni descrivono forme identiche:

interface User {
  id: number;
  name: string;
  email?: string;
}

type UserAlias = {
  id: number;
  name: string;
  email?: string;
};

const a: User = { id: 1, name: "Asha" };
const b: UserAlias = a;   // no error

TypeScript utilizza la tipizzazione strutturale, il che significa che confronta forme anziché nomi. Ecco perché un User può essere assegnato a un UserAlias senza lamentarsi. Entrambi supportano proprietà opzionali, readonly proprietà, metodi e firme di indice.

Interfaccia e tipo fianco a fianco

Ciò che solo il tipo può fare

Molti tipi utili non sono affatto forme di oggetti e solo un alias di tipo può nominarli:

type Status = "pending" | "paid" | "shipped";   // union
type Point = [number, number];                    // tuple
type Handler = (event: string) => void;           // function type
type Keys = keyof User;                           // computed type
type ReadonlyUser = Readonly<User>;               // utility type

I tipi di unione sono tra le funzionalità più preziose di TypeScript, perché il compilatore rifiuta quindi qualsiasi valore esterno all’elenco:

let s: Status = "paid";
s = "refunded";

// error TS2322: Type '"refunded"' is not assignable to type 'Status'.

Ciò rileva errori di battitura e valori obsoleti in fase di compilazione, prima che raggiungano la produzione.

Fusione delle dichiarazioni

Se dichiari due volte un’interfaccia con lo stesso nome, TypeScript le unisce in una sola:

interface Settings {
  theme: string;
}
interface Settings {
  language: string;
}

const settings: Settings = { theme: "dark", language: "en" };   // no error

Prova la stessa cosa con un alias di tipo e il compilatore rifiuta:

type Config = { theme: string };
type Config = { language: string };

// error TS2300: Duplicate identifier 'Config'.

L’unione è il modo in cui le librerie ti consentono di estendere i loro tipi. Ad esempio, puoi aggiungere una proprietà personalizzata all’interfaccia globale Window o all’oggetto richiesta di un framework, senza modificare la libreria. Questo è veramente utile.

Il rovescio della medaglia è che la fusione può avvenire per caso. Se due file in un progetto dichiarano un’interfaccia con lo stesso nome nello stesso ambito, si combinano silenziosamente, il che può creare confusione. Un alias di tipo rende invece la collisione un errore.

estensioni vs intersezioni

Entrambi ti consentono di basarti su un tipo esistente:

interface Admin extends User {
  permissions: string[];
}

type AdminAlias = UserAlias & { permissions: string[] };

Per le proprietà compatibili, il risultato è lo stesso. La differenza si manifesta con un conflitto. Quando un’interfaccia tenta di modificare il tipo di una proprietà in modo incompatibile, il compilatore lo segnala immediatamente:

interface Base { id: number }
interface Broken extends Base { id: string }

// error TS2430: Interface 'Broken' incorrectly extends interface 'Base'.
//   Types of property 'id' are incompatible.
//     Type 'string' is not assignable to type 'number'.

Un incrocio non si lamenta quando viene dichiarato. La proprietà in conflitto diventa invece never, un tipo che nessun valore può avere. L’errore appare solo successivamente, quando provi ad usarlo:

type Mixed = { id: number } & { id: string };
const m: Mixed = { id: 1 };

// error TS2322: Type 'number' is not assignable to type 'never'.

Quest’ultimo errore crea più confusione, poiché allontana dall’errore reale. Questo è un motivo pratico per preferire extends quando si creano tipi di oggetto.

Classi e implementa

Una classe può promettere di abbinare una forma utilizzando implements, e questo funziona con un’interfaccia o un alias di tipo oggetto:

class Account implements User {
  constructor(public id: number, public name: string) {}
}

Questo compilato senza errori. Nota che implements controlla solo che la classe corrisponda. Non aggiunge alcuna proprietà o codice. Una classe non può implementare un tipo di unione, poiché non esiste un’unica forma da abbinare.

Tipi di sola lettura e di utilità

I tipi di utilità come Readonly, Partial, Pick e Omit funzionano sia con le interfacce che con gli alias. Il risultato è un nuovo tipo, che in genere viene denominato con un alias di tipo:

const r: ReadonlyUser = { id: 3, name: "Dev" };
r.name = "Chitra";

// error TS2540: Cannot assign to 'name' because it is a read-only property.

Ricordare che readonly è solo un controllo in fase di compilazione. In fase di esecuzione l’oggetto è un normale JavaScript e può ancora essere modificato dal codice che ignora i tipi.

Prestazioni del compilatore

Le indicazioni sulle prestazioni del team TypeScript suggeriscono di preferire le interfacce che utilizzano extends rispetto a intersezioni di grandi dimensioni, poiché il compilatore può memorizzare nella cache le relazioni delle interfacce in modo più efficiente. Nei progetti piccoli e medi difficilmente noterai alcuna differenza. Potrebbe avere importanza in basi di codice molto grandi con tipi profondamente composti. Non lo abbiamo misurato noi stessi.

Quale dovresti usare?

Una regola ampiamente utilizzata, in linea con le indicazioni del manuale TypeScript, è:

• Utilizzare interface per le forme degli oggetti, in particolare le API pubbliche e tutto ciò che le classi implementano o altri possono estendere.
• Utilizzare type per unioni, tuple, tipi di funzione e tipi mappati o calcolati.

Alcuni team utilizzano semplicemente type ovunque e anche questo funziona bene. Ciò che conta di più è la coerenza, quindi scegli una convenzione, scrivila nella tua guida di stile e lascia che un linter la imponga. La regola consistent-type-definitions di ESLint da typescript-eslint può farlo.

Errori comuni

• Dibattito senza fine. Entrambi vanno bene per gli oggetti, quindi stabilisci la regola una volta e vai avanti.
• Unione accidentale. Il riutilizzo di un nome di interfaccia nello stesso ambito li combina silenziosamente.
• Intersezioni in conflitto. Successivamente creano never tipi con errori confusi.
• Tipi attendibili in fase di esecuzione. Vengono cancellati, quindi convalida i dati esterni.
• Utilizzare any per silenziare gli errori. Disattiva il controllo. Preferisci unknown e restringilo.

Passare da uno all’altro in una codebase esistente

Cambiare un interface in un type, o il contrario, è solitamente sicuro per le forme di oggetti semplici, perché TypeScript confronta i tipi in base alla loro struttura, non in base ai loro nomi. È necessario verificare ancora alcune cose prima di effettuare il passaggio:

• La conversione di un’interfaccia in un alias di tipo rimuove l’unione delle dichiarazioni, quindi qualsiasi seconda dichiarazione con lo stesso nome diventa un errore di identificatore duplicato.
• La conversione di un alias di tipo in un’interfaccia funziona solo per le forme degli oggetti. Unioni, tuple e tipi mappati devono rimanere come alias di tipo.
• I messaggi di errore e i passaggi del mouse sull’editor possono visualizzare il tipo in modo diverso, il che può sorprendere i compagni di squadra ma non cambia il comportamento.

Apporta la modifica in una richiesta pull mirata, esegui il compilatore in modalità rigorosa e la tua suite di test ed evita di mescolarlo con il lavoro sulle funzionalità in modo che i revisori possano vedere che nient’altro è cambiato.

Considerazioni finali

La domanda tra interfaccia e tipo ha una risposta calma: si sovrappongono per gli oggetti, ognuno ha alcune abilità uniche e la coerenza conta più della scelta. Utilizza le interfacce per forme e tipi per tutto il resto, a meno che il tuo team non preferisca diversamente. Per vedere tu stesso le differenze, copia gli esempi sopra in un file ed esegui tsc --noEmit --strict su di esso.

Domande frequenti

Continua a imparare