Weinig TypeScript-vragen veroorzaken zoveel discussie als TypeScript-interface versus type. Veel artikelen vermelden verschillen die er in oudere versies toe deden, maar nu verouderd zijn. Dus in plaats van beweringen te herhalen, hebben we ze getest.

We hebben één bestand geschreven waarin we elk verschil hebben gecontroleerd, en dit hebben we gecontroleerd met TypeScript 5.6.3 in de strikte modus. De hieronder genoemde compilerfouten zijn afkomstig van die run. Gedrag kan tussen versies veranderen, dus controleer het met de TypeScript-versie die uw project gebruikt. Als je nieuw bent in de taal, begin dan met onze TypeScript-tutorial voor beginners.

Het korte antwoord

Een interface beschrijft de vorm van een object en kan worden uitgebreid of heropend. Een type alias geeft een naam aan elk type, inclusief objecten, unies, tupels en functietypen. Waar beide kunnen werken, zit het verschil vooral in stijl.

Waar ze hetzelfde zijn

Deze twee verklaringen beschrijven identieke vormen:

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 gebruikt structureel typen, wat betekent dat het vormen vergelijkt in plaats van namen. Daarom kan een User zonder klachten aan een UserAlias worden toegewezen. Beide ondersteunen optionele eigenschappen, readonly eigenschappen, methoden en indexhandtekeningen.

Interface versus type naast elkaar

Wat alleen typen kan doen

Veel nuttige typen zijn helemaal geen objectvormen, en alleen een typealias kan ze een naam geven:

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

Union-typen behoren tot de meest waardevolle functies van TypeScript, omdat de compiler vervolgens elke waarde buiten de lijst afwijst:

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

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

Hiermee worden typefouten en verouderde waarden opgespoord tijdens het compileren, voordat ze in productie gaan.

Verklaring samenvoegen

Als u een interface met dezelfde naam tweemaal declareert, voegt TypeScript deze samen tot één interface:

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

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

Probeer hetzelfde met een typealias, en de compiler weigert:

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

// error TS2300: Duplicate identifier 'Config'.

Door samen te voegen kunt u met bibliotheken hun typen uitbreiden. U kunt bijvoorbeeld een aangepaste eigenschap toevoegen aan de globale Window-interface of aan het aanvraagobject van een raamwerk, zonder de bibliotheek te wijzigen. Dat is echt nuttig.

De keerzijde is dat fusies per ongeluk kunnen gebeuren. Als twee bestanden in een project een interface met dezelfde naam in hetzelfde bereik declareren, worden ze stilzwijgend gecombineerd, wat verwarrend kan zijn. Een typealias maakt van die botsing een fout.

verlengt versus kruispunten

Met beide kun je voortbouwen op een bestaand type:

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

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

Voor compatibele eigenschappen is het resultaat hetzelfde. Het verschil komt tot uiting in een conflict. Wanneer een interface het type van een eigenschap op incompatibele wijze probeert te wijzigen, rapporteert de compiler dit onmiddellijk:

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'.

Een kruispunt klaagt niet wanneer het wordt aangegeven. In plaats daarvan wordt de conflicterende eigenschap never, een type dat geen enkele waarde kan hebben. De fout verschijnt pas later, wanneer u deze probeert te gebruiken:

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

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

Die latere fout is nog verwarrender, omdat deze wegwijst van de feitelijke fout. Dit is een praktische reden om de voorkeur te geven aan extends bij het opbouwen van objecttypen.

Klassen en werktuigen

Een klasse kan beloven een vorm te matchen met behulp van implements, en dit werkt met een interface of een objecttype-alias:

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

Deze is zonder fouten samengesteld. Merk op dat implements alleen controleert of de klasse overeenkomt. Er worden geen eigenschappen of code toegevoegd. Een klasse kan geen unietype implementeren, omdat er geen enkele vorm is die daarbij past.

Alleen-lezen en hulpprogrammatypen

Hulpprogrammatypen zoals Readonly, Partial, Pick en Omit werken met zowel interfaces als aliassen. Het resultaat is een nieuw type, dat doorgaans wordt benoemd met een typealias:

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

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

Houd er rekening mee dat readonly alleen een controle tijdens het compileren is. Tijdens runtime is het object gewoon JavaScript en kan het nog steeds worden gewijzigd door code die de typen omzeilt.

Compilerprestaties

De eigen prestatierichtlijnen van het TypeScript-team suggereren dat de voorkeur wordt gegeven aan interfaces die extends gebruiken boven grote kruispunten, omdat de compiler interfacerelaties efficiënter in de cache kan opslaan. Bij kleine en middelgrote projecten is het onwaarschijnlijk dat u enig verschil merkt. Het kan ertoe doen in zeer grote codebases met diep samengestelde typen. Wij hebben dit zelf niet gemeten.

Welke moet je gebruiken?

Een veelgebruikte regel, in lijn met de richtlijnen van het TypeScript-handboek, is:

• Gebruik interface voor objectvormen, vooral openbare API’s en alles wat klassen implementeren of door anderen kunnen worden uitgebreid.
• Gebruik type voor verbindingen, tupels, functietypen en toegewezen of berekende typen.

Sommige teams gebruiken type gewoon overal, en dat werkt ook prima. Het belangrijkste is consistentie, dus kies een conventie, schrijf deze in je stijlgids en laat een linter deze afdwingen. ESLint’s consistent-type-definitions regel van typescript-eslint kan dit doen.

Veel voorkomende fouten

• Eindeloze discussies. Beide zijn prima voor objecten, dus bepaal de regel één keer en ga verder.
• Per ongeluk samenvoegen. Door een interfacenaam binnen hetzelfde bereik opnieuw te gebruiken, worden deze op de achtergrond gecombineerd.
• Conflicterende kruispunten. Ze creëren never typen met later verwarrende fouten.
• Vertrouwde typen tijdens runtime. Ze worden gewist, dus valideer externe gegevens.
• Gebruik any om fouten uit te sluiten. De controle wordt uitgeschakeld. Geef de voorkeur aan unknown en beperk het.

Ertussen schakelen in een bestaande codebase

Het veranderen van een interface in een type, of omgekeerd, is meestal veilig voor gewone objectvormen, omdat TypeScript typen vergelijkt op basis van hun structuur, niet op basis van hun naam. Er zijn nog een aantal zaken die je moet controleren voordat je overstapt:

• Door een interface naar een typealias te converteren, wordt het samenvoegen van declaraties verwijderd, zodat elke tweede declaratie met dezelfde naam een dubbele identificatiefout wordt.
• Het converteren van een typealias naar een interface werkt alleen voor objectvormen. Vakbonden, tupels en toegewezen typen moeten als typealiassen blijven.
• Foutmeldingen en hovers van de editor kunnen het type anders weergeven, wat teamgenoten kan verrassen maar het gedrag niet verandert.

Voer de wijziging door in één gerichte pull-request, voer de compiler uit in de strikte modus en uw testpakket, en vermijd het vermengen ervan met functiewerk, zodat reviewers kunnen zien dat er verder niets is veranderd.

Tot slot

De interface versus type-vraag heeft een rustig antwoord: ze overlappen elkaar voor objecten, elk heeft een paar unieke vaardigheden, en consistentie is belangrijker dan de keuze. Gebruik interfaces voor vormen en typen voor al het andere, tenzij uw team anders verkiest. Om zelf de verschillen te zien, kopieert u de bovenstaande voorbeelden naar een bestand en voert u daarop tsc --noEmit --strict uit.

Veelgestelde vragen

Blijf leren