Peu de questions TypeScript suscitent autant de débats que Interface TypeScript vs type. De nombreux articles répertorient les différences qui étaient importantes dans les anciennes versions, mais qui sont désormais obsolètes. Ainsi, plutôt que de répéter des affirmations, nous les avons testées.

Nous avons écrit un fichier exerçant chaque différence et l’avons vérifié avec TypeScript 5.6.3 en mode strict. Les erreurs du compilateur citées ci-dessous proviennent de cette exécution. Le comportement peut changer entre les versions, alors vérifiez par rapport à la version TypeScript utilisée par votre projet. Si vous êtes nouveau dans le langage, commencez par notre Tutoriel TypeScript pour débutants.

La réponse courte

Un interface décrit la forme d’un objet et peut être étendu ou rouvert. Un alias type donne un nom à n’importe quel type, y compris les objets, les unions, les tuples et les types de fonctions. Là où les deux peuvent fonctionner, la différence réside principalement dans le style.

Où ils sont pareils

Ces deux déclarations décrivent des formes identiques :

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 utilise le typage structurel, ce qui signifie qu’il compare les formes plutôt que les noms. C’est pourquoi un User peut être attribué à un UserAlias sans aucune plainte. Les deux prennent en charge les propriétés facultatives, les propriétés readonly, les méthodes et les signatures d’index.

Interface vs type côte à côte

Ce que seul le type peut faire

De nombreux types utiles ne sont pas du tout des formes d’objet, et seul un alias de type peut les nommer :

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

Les types d’union font partie des fonctionnalités les plus précieuses de TypeScript, car le compilateur rejette ensuite toute valeur en dehors de la liste :

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

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

Cela détecte les fautes de frappe et les valeurs obsolètes au moment de la compilation, avant qu’elles n’atteignent la production.

Fusion de déclarations

Si vous déclarez deux fois une interface portant le même nom, TypeScript les fusionne en une seule :

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

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

Essayez la même chose avec un alias de type, et le compilateur refuse :

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

// error TS2300: Duplicate identifier 'Config'.

La fusion est la façon dont les bibliothèques vous permettent d’étendre leurs types. Par exemple, vous pouvez ajouter une propriété personnalisée à l’interface globale Window ou à l’objet de requête d’un framework, sans modifier la bibliothèque. C’est vraiment utile.

Le revers de la médaille est que la fusion peut se produire par accident. Si deux fichiers d’un projet déclarent une interface portant le même nom dans la même portée, ils se combinent silencieusement, ce qui peut prêter à confusion. Un alias de type fait de cette collision une erreur.

s’étend par rapport aux intersections

Les deux vous permettent de construire sur un type existant :

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

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

Pour les propriétés compatibles, le résultat est le même. La différence se manifeste par un conflit. Lorsqu’une interface tente de modifier le type d’une propriété de manière incompatible, le compilateur le signale immédiatement :

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

Une intersection ne se plaint pas lorsqu’elle est déclarée. Au lieu de cela, la propriété en conflit devient never, un type qu’aucune valeur ne peut avoir. L’erreur n’apparaît que plus tard, lorsque vous essayez de l’utiliser :

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

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

Cette erreur ultérieure est plus déroutante, car elle s’éloigne de l’erreur réelle. C’est une raison pratique de préférer extends lors de la création de types d’objets.

Classes et outils

Une classe peut promettre de correspondre à une forme en utilisant implements, et cela fonctionne avec une interface ou un alias de type d’objet :

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

Ceci compilé sans erreurs. Notez que implements vérifie uniquement que la classe correspond. Il n’ajoute aucune propriété ni code. Une classe ne peut pas implémenter un type d’union, puisqu’il n’existe pas de forme unique à laquelle correspondre.

Types en lecture seule et utilitaires

Les types d’utilitaires tels que Readonly, Partial, Pick et Omit fonctionnent à la fois avec les interfaces et les alias. Le résultat est un nouveau type, généralement nommé avec un alias de type :

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

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

N’oubliez pas que readonly est uniquement une vérification au moment de la compilation. Au moment de l’exécution, l’objet est du JavaScript ordinaire et il peut toujours être modifié par du code qui contourne les types.

Performances du compilateur

Les propres conseils de performance de l’équipe TypeScript suggèrent de préférer les interfaces qui utilisent extends aux grandes intersections, car le compilateur peut mettre en cache les relations d’interface plus efficacement. Dans les petits et moyens projets, il est peu probable que vous remarquiez une différence. Cela peut avoir de l’importance dans les bases de code très volumineuses avec des types profondément composés. Nous ne l’avons pas mesuré nous-mêmes.

Lequel devriez-vous utiliser ?

Une règle largement utilisée, conformément aux conseils du manuel TypeScript, est la suivante :

• Utilisez interface pour les formes d’objets, en particulier les API publiques et tout ce que les classes implémentent ou que d’autres peuvent étendre.
• Utilisez type pour les unions, les tuples, les types de fonctions et les types mappés ou calculés.

Certaines équipes utilisent simplement type partout, et cela fonctionne également bien. Ce qui compte le plus, c’est la cohérence, alors choisissez une convention, écrivez-la dans votre guide de style et laissez un linter l’appliquer. La règle ESLint consistent-type-definitions de typescript-eslint peut le faire.

Erreurs courantes

• Débat sans fin. Les deux conviennent parfaitement aux objets, alors définissez la règle une fois et passez à autre chose.
• Fusion accidentelle. La réutilisation d’un nom d’interface dans la même portée les combine silencieusement.
• Intersections conflictuelles. Ils créent plus tard never types avec des erreurs déroutantes.
• Types de confiance au moment de l’exécution. Ils sont effacés, donc validez les données externes.
• Utiliser any pour faire taire les erreurs. Cela désactive la vérification. Préférez unknown et réduisez-le.

Basculer entre eux dans une base de code existante

Changer un interface en type, ou l’inverse, est généralement sans danger pour les formes d’objet simples, car TypeScript compare les types par leur structure, et non par leurs noms. Quelques éléments doivent encore être vérifiés avant de changer :

• La conversion d’une interface en alias de type supprime la fusion des déclarations, de sorte que toute deuxième déclaration portant le même nom devient une erreur d’identifiant en double.
• La conversion d’un alias de type en interface ne fonctionne que pour les formes d’objet. Les unions, les tuples et les types mappés doivent rester sous forme d’alias de type.
• Les messages d’erreur et les survols de l’éditeur peuvent afficher le type différemment, ce qui peut surprendre les coéquipiers mais ne change pas le comportement.

Effectuez la modification en une seule demande d’extraction ciblée, exécutez le compilateur en mode strict et votre suite de tests, et évitez de la mélanger avec le travail sur les fonctionnalités afin que les réviseurs puissent voir que rien d’autre n’a changé.

Pour conclure

La question interface vs type a une réponse calme : ils se chevauchent pour les objets, chacun a quelques capacités uniques et la cohérence compte plus que le choix. Utilisez des interfaces pour les formes et les types pour tout le reste, à moins que votre équipe ne préfère autrement. Pour voir les différences vous-même, copiez les exemples ci-dessus dans un fichier et exécutez tsc --noEmit --strict dessus.

Questions fréquentes

Continuez à apprendre