interface vs type: la regla para no dudar más

La pregunta que divide equipos y llena hilos de Stack Overflow: ¿interface o type? La verdad tranquilizadora: para describir un objeto, son casi idénticos y casi nunca importa. Pero hay diferencias reales, y una regla práctica simple que te deja decidir en un segundo y no volver a pensarlo. Hoy la grabas.

Casi gemelos, con talentos propios

Lo que solo puede type

type es un "alias de CUALQUIER tipo", no solo de objetos. Puede nombrar cosas que interface no:

// uniones: SOLO type
type Estado = "cargando" | "listo" | "error";
type Id = number | string;

// tuplas: SOLO type
type Coordenada = [number, number];

// alias de un primitivo o de una función suelta: SOLO type
type Edad = number;
type Comparador = (a: number, b: number) => number;

// tipos derivados/avanzados (módulos 6 y 7): SOLO type
type SoloLectura = Readonly<Estado>;

// una interface NO puede describir nada de esto: es solo para FORMAS de objeto

Uniones, tuplas, alias de primitivos, tipos de función sueltos, tipos avanzados: todo eso es territorio EXCLUSIVO de type. Una interface solo describe la forma de un objeto (o de una función/clase), nada más. Por eso type es la herramienta más general.

Lo que solo puede interface

interface tiene dos talentos que type no:

// 1. DECLARATION MERGING: dos interfaces del mismo nombre se fusionan (lección 3).
//    Clave para ampliar tipos de librerías (Window, Express, etc.):
interface Window { miApp: string }   // añade miApp al Window global

// 2. Mensajes de error y rendimiento ligeramente mejores en jerarquías grandes
//    con 'extends' (detalle interno del compilador; rara vez decisivo).

// type NO puede fusionarse: dos 'type X' con el mismo nombre es un ERROR.

El talento decisivo es el declaration merging: solo las interfaces se fusionan por nombre, y eso es lo que permite extender tipos que no controlas. Si escribes una librería cuyos tipos otros deban ampliar, o si amplías tipos globales, necesitas interface.

La regla práctica

No te obsesiones

Este es uno de esos debates que consumen más energía de la que merecen. Para el 99% de tu código —describir la forma de tus datos— las dos funcionan idéntico, y podrías cambiar una por otra sin que nada se rompa. Aprende las diferencias reales (las de arriba), aplica la regla, y dedica tu atención a lo que sí mueve la aguja: modelar bien tus datos. La herramienta importa menos que el modelo.

Mini-reto

Aplica la regla a un modelo real, decidiendo herramienta por herramienta: 1) el estado de una petición "idle" | "cargando" | "ok" | "error" → ¿type o interface? 2) la forma de un Usuario con id, nombre y email → ¿cuál, y importa? 3) un tipo para el par [latitud, longitud] → ¿cuál puede? Justifica cada elección con la regla. (Respuestas: 1 type -unión-; 2 cualquiera, sé consistente; 3 type -tupla-.)

Qué sigue

Cierras la parte de funciones con una técnica de nicho pero poderosa: las SOBRECARGAS —darle a una función varias firmas para que se comporte (y tipe) distinto según cómo la llames. Cuándo valen la pena y cuándo hay algo mejor.