Nur wenige TypeScript-Fragen sorgen für so viele Debatten wie TypeScript-Schnittstelle vs. Typ. In vielen Artikeln werden Unterschiede aufgeführt, die in älteren Versionen eine Rolle spielten, jetzt aber veraltet sind. Anstatt also Behauptungen zu wiederholen, haben wir sie getestet.

Wir haben eine Datei geschrieben, die jeden Unterschied ausübt, und sie mit TypeScript 5.6.3 im strikten Modus überprüft. Die unten aufgeführten Compilerfehler stammen aus diesem Lauf. Das Verhalten kann sich zwischen den Versionen ändern. Vergleichen Sie es daher mit der TypeScript-Version, die Ihr Projekt verwendet. Wenn Sie neu in der Sprache sind, beginnen Sie mit unserem TypeScript-Tutorial für Anfänger.

Die kurze Antwort

Eine interface beschreibt die Form eines Objekts und kann erweitert oder erneut geöffnet werden. Ein type-Alias ​​gibt einem jedem Typ einen Namen, einschließlich Objekten, Unions, Tupeln und Funktionstypen. Wo beides funktionieren kann, liegt der Unterschied hauptsächlich im Stil.

Wo sie gleich sind

Diese beiden Deklarationen beschreiben identische Formen:

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 verwendet strukturelle Typisierung, was bedeutet, dass es Formen statt Namen vergleicht. Deshalb kann eine User ohne Beanstandung einer UserAlias zugeordnet werden. Beide unterstützen optionale Eigenschaften, readonly Eigenschaften, Methoden und Indexsignaturen.

Schnittstelle vs. Typ nebeneinander

Was nur Typ kann

Viele nützliche Typen sind überhaupt keine Objektformen und können nur mit einem Typalias benannt werden:

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 gehören zu den wertvollsten Funktionen von TypeScript, da der Compiler dann jeden Wert außerhalb der Liste ablehnt:

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

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

Dadurch werden Tippfehler und veraltete Werte zur Kompilierungszeit erkannt, bevor sie in die Produktion gelangen.

Deklarationszusammenführung

Wenn Sie eine Schnittstelle mit demselben Namen zweimal deklarieren, führt TypeScript sie zu einer zusammen:

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

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

Versuchen Sie dasselbe mit einem Typalias, aber der Compiler weigert sich:

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

// error TS2300: Duplicate identifier 'Config'.

Durch das Zusammenführen können Sie mit Bibliotheken ihre Typen erweitern. Beispielsweise können Sie eine benutzerdefinierte Eigenschaft zur globalen Window-Schnittstelle oder zum Anforderungsobjekt eines Frameworks hinzufügen, ohne die Bibliothek zu ändern. Das ist wirklich nützlich.

Die Kehrseite ist, dass eine Zusammenführung zufällig erfolgen kann. Wenn zwei Dateien in einem Projekt eine Schnittstelle mit demselben Namen im selben Bereich deklarieren, werden sie stillschweigend kombiniert, was verwirrend sein kann. Ein Typalias macht diese Kollision stattdessen zu einem Fehler.

erstreckt sich vs. Kreuzungen

Mit beiden können Sie auf einem vorhandenen Typ aufbauen:

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

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

Bei kompatiblen Eigenschaften ist das Ergebnis dasselbe. Der Unterschied zeigt sich in einem Konflikt. Wenn eine Schnittstelle versucht, den Typ einer Eigenschaft inkompatibel zu ändern, meldet der Compiler dies sofort:

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

Eine Kreuzung beschwert sich nicht, wenn sie deklariert wird. Stattdessen wird die widersprüchliche Eigenschaft zu never, einem Typ, den kein Wert haben kann. Der Fehler tritt erst später auf, wenn Sie versuchen, ihn zu verwenden:

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

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

Dieser spätere Fehler ist verwirrender, da er vom eigentlichen Fehler abweicht. Dies ist ein praktischer Grund, extends beim Aufbau von Objekttypen zu bevorzugen.

Klassen und Implementierungen

Eine Klasse kann mithilfe von implements versprechen, einer Form zu entsprechen, und dies funktioniert mit einer Schnittstelle oder einem Objekttyp-Alias:

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

Dies wurde ohne Fehler kompiliert. Beachten Sie, dass implements nur prüft, ob die Klasse übereinstimmt. Es werden keine Eigenschaften oder Code hinzugefügt. Eine Klasse kann keinen Union-Typ implementieren, da es keine einzelne passende Form gibt.

Schreibgeschützte und Dienstprogrammtypen

Dienstprogrammtypen wie Readonly, Partial, Pick und Omit funktionieren sowohl mit Schnittstellen als auch mit Aliasen. Das Ergebnis ist ein neuer Typ, der normalerweise mit einem Typalias benannt wird:

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

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

Denken Sie daran, dass readonly nur eine Überprüfung zur Kompilierungszeit ist. Zur Laufzeit handelt es sich bei dem Objekt um normales JavaScript und es kann dennoch durch Code geändert werden, der die Typen umgeht.

Compiler-Leistung

Die eigenen Leistungsrichtlinien des TypeScript-Teams schlagen vor, Schnittstellen, die extends verwenden, gegenüber großen Schnittmengen zu bevorzugen, da der Compiler Schnittstellenbeziehungen effizienter zwischenspeichern kann. Bei kleinen und mittleren Projekten werden Sie wahrscheinlich keinen Unterschied bemerken. Dies kann in sehr großen Codebasen mit tief zusammengesetzten Typen von Bedeutung sein. Wir haben dies nicht selbst gemessen.

Welches sollten Sie verwenden?

Eine weit verbreitete Regel, die den Leitlinien des TypeScript-Handbuchs entspricht, lautet:

• Verwenden Sie interface für Objektformen, insbesondere öffentliche APIs und alles, was Klassen implementieren oder andere erweitern können.
• Verwenden Sie type für Vereinigungen, Tupel, Funktionstypen und zugeordnete oder berechnete Typen.

Manche Teams verwenden einfach überall type, und das funktioniert auch gut. Am wichtigsten ist die Konsistenz. Wählen Sie also eine Konvention, schreiben Sie sie in Ihren Styleguide und lassen Sie sie von einem Linter durchsetzen. Die consistent-type-definitions-Regel von ESLint aus typescript-eslint kann dies tun.

Häufige Fehler

• Endlose Debatte. Beides ist für Objekte in Ordnung, also klären Sie die Regel einmal und machen Sie weiter.
• Versehentliches Zusammenführen. Die Wiederverwendung eines Schnittstellennamens im selben Bereich führt diese stillschweigend zusammen.
• Widersprüchliche Schnittmengen. Sie erstellen später never Typen mit verwirrenden Fehlern.
• Typen zur Laufzeit vertrauen. Sie werden gelöscht, also validieren Sie externe Daten.
• Verwendung von any zum Stummschalten von Fehlern. Die Überprüfung wird ausgeschaltet. Bevorzugen Sie unknown und grenzen Sie es ein.

Wechseln zwischen ihnen in einer vorhandenen Codebasis

Das Ändern einer interface in eine type oder umgekehrt ist für einfache Objektformen normalerweise sicher, da TypeScript Typen anhand ihrer Struktur und nicht anhand ihrer Namen vergleicht. Vor dem Wechsel müssen noch einige Dinge überprüft werden:

• Durch das Konvertieren einer Schnittstelle in einen Typalias wird die Deklarationszusammenführung aufgehoben, sodass jede zweite Deklaration mit demselben Namen zu einem Fehler wegen doppelter Bezeichner wird.
• Das Konvertieren eines Typalias in eine Schnittstelle funktioniert nur für Objektformen. Unions, Tupel und zugeordnete Typen müssen als Typaliase bleiben.
• Fehlermeldungen und Editor-Hover zeigen den Typ möglicherweise anders an, was Teamkollegen überraschen kann, aber das Verhalten nicht ändert.

Nehmen Sie die Änderung in einem fokussierten Pull-Request vor, führen Sie den Compiler im strikten Modus und Ihre Testsuite aus und vermeiden Sie eine Vermischung mit Feature-Arbeit, damit Prüfer sehen können, dass sich sonst nichts geändert hat.

Fazit

Auf die Frage zwischen Schnittstelle und Typ gibt es eine klare Antwort: Sie überschneiden sich bei Objekten, jedes hat ein paar einzigartige Fähigkeiten und Konsistenz ist wichtiger als die Auswahl. Verwenden Sie für alles andere Schnittstellen für Formen und Typen, sofern Ihr Team nichts anderes bevorzugt. Um die Unterschiede selbst zu sehen, kopieren Sie die obigen Beispiele in eine Datei und führen Sie tsc --noEmit --strict darauf aus.

Häufige Fragen

Lerne weiter