Pocas preguntas sobre TypeScript causan tanto debate como Interfaz de TypeScript versus tipo. Muchos artículos enumeran diferencias que solían ser importantes en versiones anteriores pero que ahora están desactualizadas. Entonces, en lugar de repetir afirmaciones, las probamos.

Escribimos un archivo practicando cada diferencia y lo verificamos con TypeScript 5.6.3 en modo estricto. Los errores del compilador que se citan a continuación provienen de esa ejecución. El comportamiento puede cambiar entre versiones, así que compruébelo con la versión de TypeScript que utiliza su proyecto. Si eres nuevo en el lenguaje, comienza con nuestro tutorial de TypeScript para principiantes.

La respuesta corta

Un interface describe la forma de un objeto y se puede ampliar o reabrir. Un alias type da un nombre a cualquier tipo, incluidos objetos, uniones, tuplas y tipos de funciones. Cuando ambos pueden funcionar, la diferencia es principalmente el estilo.

donde son iguales

Estas dos declaraciones describen formas idénticas:

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 utiliza tipificación estructural, lo que significa que compara formas en lugar de nombres. Por eso se puede asignar un User a un UserAlias sin queja alguna. Ambos admiten propiedades opcionales, readonly propiedades, métodos y firmas de índice.

Interfaz versus tipo uno al lado del otro

¿Qué solo el tipo puede hacer?

Muchos tipos útiles no son formas de objetos en absoluto, y sólo un alias de tipo puede nombrarlos:

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

Los tipos de unión se encuentran entre las características más valiosas de TypeScript, porque el compilador rechaza cualquier valor fuera de la lista:

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

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

Esto detecta errores tipográficos y valores obsoletos en el momento de la compilación, antes de que lleguen a producción.

Declaración de fusión

Si declara una interfaz con el mismo nombre dos veces, TypeScript las fusiona en una:

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

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

Intente lo mismo con un alias de tipo y el compilador se niega:

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

// error TS2300: Duplicate identifier 'Config'.

La fusión es la forma en que las bibliotecas le permiten ampliar sus tipos. Por ejemplo, puede agregar una propiedad personalizada a la interfaz global Window o al objeto de solicitud de un marco, sin modificar la biblioteca. Eso es realmente útil.

La otra cara de la moneda es que la fusión puede ocurrir por accidente. Si dos archivos en un proyecto declaran una interfaz con el mismo nombre en el mismo ámbito, se combinan silenciosamente, lo que puede resultar confuso. Un alias de tipo hace que esa colisión sea un error.

se extiende vs intersecciones

Ambos le permiten construir sobre un tipo existente:

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

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

Para propiedades compatibles, el resultado es el mismo. La diferencia se manifiesta con un conflicto. Cuando una interfaz intenta cambiar el tipo de propiedad de manera incompatible, el compilador lo informa de inmediato:

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

Una intersección no se queja cuando se declara. En cambio, la propiedad en conflicto se convierte en never, un tipo que ningún valor puede tener. El error solo aparece más tarde, cuando intentas usarlo:

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

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

Ese error posterior es más confuso, ya que apunta fuera del error real. Ésta es una razón práctica para preferir extends al crear tipos de objetos.

Clases e implementos.

Una clase puede prometer hacer coincidir una forma usando implements, y esto funciona con una interfaz o un alias de tipo de objeto:

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

Esta compilado sin errores. Tenga en cuenta que implements solo verifica que la clase coincida. No agrega ninguna propiedad ni código. Una clase no puede implementar un tipo de unión, ya que no existe una forma única que coincida.

Tipos de utilidad y de solo lectura

Los tipos de utilidades como Readonly, Partial, Pick y Omit funcionan tanto con interfaces como con alias. El resultado es un nuevo tipo, que normalmente recibe un nombre con un alias de tipo:

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

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

Recuerde que readonly es solo una verificación en tiempo de compilación. En tiempo de ejecución, el objeto es JavaScript normal y aún se puede cambiar mediante código que omita los tipos.

Rendimiento del compilador

La propia guía de rendimiento del equipo de TypeScript sugiere preferir interfaces que usan extends en lugar de intersecciones grandes, porque el compilador puede almacenar en caché las relaciones de interfaz de manera más eficiente. En proyectos pequeños y medianos es poco probable que notes alguna diferencia. Puede ser importante en bases de código muy grandes con tipos profundamente compuestos. No lo medimos nosotros mismos.

¿Cuál deberías usar?

Una regla ampliamente utilizada, de acuerdo con las pautas del manual de TypeScript, es:

• Utilice interface para formas de objetos, especialmente API públicas y cualquier cosa que implementen las clases u otras puedan extenderse.
• Utilice type para uniones, tuplas, tipos de funciones y tipos asignados o calculados.

Algunos equipos simplemente usan type en todas partes y eso también funciona bien. Lo que más importa es la coherencia, así que elige una convención, escríbela en tu guía de estilo y deja que un linter la haga cumplir. La regla ESLint consistent-type-definitions de mecanografiado-eslint puede hacer esto.

Errores comunes

• Debate sin fin. Ambos están bien para los objetos, así que establece la regla una vez y sigue adelante.
• Fusión accidental. La reutilización de un nombre de interfaz en el mismo ámbito los combina silenciosamente.
• Intersecciones conflictivas. Crean never tipos con errores confusos más adelante.
• Tipos de confianza en tiempo de ejecución. Se borran, así que valide los datos externos.
• Usando any para silenciar errores. Desactiva la comprobación. Prefiera unknown y limítelo.

Cambiar entre ellos en una base de código existente

Cambiar un interface por un type, o al revés, suele ser seguro para formas de objetos simples, porque TypeScript compara los tipos por su estructura, no por sus nombres. Aún es necesario comprobar algunas cosas antes de cambiar:

• La conversión de una interfaz a un alias de tipo elimina la fusión de declaraciones, por lo que cualquier segunda declaración con el mismo nombre se convierte en un error de identificador duplicado.
• La conversión de un alias de tipo en una interfaz solo funciona para formas de objetos. Las uniones, tuplas y tipos mapeados deben permanecer como alias de tipo.
• Los mensajes de error y los desplazamientos del editor pueden mostrar el tipo de forma diferente, lo que puede sorprender a los compañeros de equipo pero no cambia el comportamiento.

Realice el cambio en una solicitud de extracción enfocada, ejecute el compilador en modo estricto y su conjunto de pruebas, y evite mezclarlo con el trabajo de funciones para que los revisores puedan ver que nada más cambió.

Conclusión

La pregunta entre interfaz y tipo tiene una respuesta tranquila: se superponen para los objetos, cada uno tiene algunas habilidades únicas y la coherencia importa más que la elección. Utilice interfaces para formas y tipos para todo lo demás, a menos que su equipo prefiera lo contrario. Para ver las diferencias usted mismo, copie los ejemplos anteriores en un archivo y ejecute tsc --noEmit --strict en él.

Preguntas frecuentes

sigue aprendiendo