Лишь немногие вопросы о TypeScript вызывают столько споров, как Интерфейс TypeScript и тип. Во многих статьях перечислены различия, которые раньше имели значение в старых версиях, но теперь устарели. Поэтому вместо того, чтобы повторять утверждения, мы проверили их.

Мы написали по одному файлу, реализующему каждое различие, и проверили его с помощью TypeScript 5.6.3 в строгом режиме. Ошибки компилятора, приведенные ниже, происходят из-за этого запуска. Поведение может меняться в зависимости от версии, поэтому проверьте версию TypeScript, которую использует ваш проект. Если вы новичок в этом языке, начните с нашего учебника по TypeScript для начинающих.

Короткий ответ

interface описывает форму объекта и может быть расширен или открыт повторно. Псевдоним type дает имя любому типу, включая объекты, объединения, кортежи и типы функций. Там, где могут работать оба, разница в основном заключается в стиле.

Где они одинаковы

Эти два объявления описывают идентичные формы:

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 использует структурную типизацию, что означает, что он сравнивает формы, а не имена. Вот почему User можно без проблем назначить на UserAlias. Оба поддерживают дополнительные свойства, readonly свойства, методы и сигнатуры индексов.

Интерфейс и тип рядом

Что может только тип

Многие полезные типы вообще не являются фигурами объектов, и их можно назвать только псевдонимом типа:

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

Типы объединения являются одной из наиболее ценных функций TypeScript, поскольку компилятор отклоняет любое значение за пределами списка:

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

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

Это позволяет обнаружить опечатки и устаревшие значения во время компиляции, прежде чем они попадут в рабочую среду.

Объединение деклараций

Если вы дважды объявите интерфейс с одним и тем же именем, TypeScript объединит их в один:

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

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

Попробуйте то же самое с псевдонимом типа, и компилятор откажет:

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

// error TS2300: Duplicate identifier 'Config'.

Слияние — это то, как библиотеки позволяют расширять свои типы. Например, вы можете добавить пользовательское свойство в глобальный интерфейс Window или в объект запроса платформы, не изменяя библиотеку. Это действительно полезно.

Обратной стороной является то, что слияние может произойти случайно. Если два файла в проекте объявляют интерфейс с одинаковым именем в одной области, они автоматически объединяются, что может сбить с толку. Вместо этого псевдоним типа делает это столкновение ошибкой.

расширяется против пересечений

Оба позволяют использовать существующий тип:

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

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

Для совместимых свойств результат тот же. Разница проявляется в конфликте. Когда интерфейс пытается изменить тип свойства несовместимым образом, компилятор сразу сообщает об этом:

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

Перекресток не вызывает жалоб при его объявлении. Вместо этого конфликтующее свойство становится never, тип которого не может иметь ни одно значение. Ошибка появляется только позже, когда вы пытаетесь ее использовать:

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

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

Эта более поздняя ошибка еще больше сбивает с толку, поскольку она указывает на настоящую ошибку. Это одна из практических причин отдать предпочтение extends при создании типов объектов.

Классы и орудия

Класс может обещать соответствовать форме, используя implements, и это работает с интерфейсом или псевдонимом типа объекта:

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

Это скомпилировано без ошибок. Обратите внимание, что implements проверяет только соответствие класса. Он не добавляет никаких свойств или кода. Класс не может реализовать тип объединения, поскольку не существует единой формы, которой можно было бы соответствовать.

Только чтение и типы утилит

Типы утилит, такие как Readonly, Partial, Pick и Omit, работают как с интерфейсами, так и с псевдонимами. Результатом является новый тип, которому обычно присваивается псевдоним типа:

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

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

Помните, что readonly — это проверка только во время компиляции. Во время выполнения объект представляет собой обычный JavaScript, и его по-прежнему можно изменить с помощью кода, обходящего типы.

Производительность компилятора

Собственные рекомендации по производительности команды TypeScript предлагают отдавать предпочтение интерфейсам, использующим extends, а не большим пересечениям, поскольку компилятор может более эффективно кэшировать отношения между интерфейсами. В малых и средних проектах вы вряд ли заметите какую-либо разницу. Это может иметь значение в очень больших базах кода с глубоко составленными типами. Мы сами это не измеряли.

Что вам следует использовать?

Широко используемое правило, соответствующее рекомендациям руководства по TypeScript, гласит:

• Используйте interface для фигур объектов, особенно общедоступных API и всего, что реализуют классы или могут расширять другие.
• Используйте type для объединений, кортежей, типов функций, а также отображаемых или вычисляемых типов.

Некоторые команды просто везде используют type, и это тоже хорошо работает. Самое главное — это последовательность, поэтому выберите соглашение, запишите его в своем руководстве по стилю и позвольте линтеру обеспечить его соблюдение. Правило ESLint consistent-type-definitions из typescript-eslint позволяет это сделать.

Распространенные ошибки

• Бесконечные дебаты. Оба варианта хороши для объектов, поэтому установите правило один раз и двигайтесь дальше.
• Случайное слияние. Повторное использование имени интерфейса в одной области незаметно объединяет их.
• Конфликтующие пересечения. Позже они создают never типы с запутанными ошибками.
• Доверительные типы во время выполнения. Они удаляются, поэтому проверяйте внешние данные.
• Использование any для отключения ошибок. Отключает проверку. Отдайте предпочтение unknown и сузьте его.

Переключение между ними в существующей кодовой базе

Изменение interface на type или наоборот обычно безопасно для простых фигур объектов, поскольку TypeScript сравнивает типы по их структуре, а не по именам. Перед переключением все еще необходимо проверить несколько вещей:

• Преобразование интерфейса в псевдоним типа устраняет слияние объявлений, поэтому любое второе объявление с тем же именем становится ошибкой дублирующегося идентификатора.
• Преобразование псевдонима типа в интерфейс работает только для фигур объектов. Объединения, кортежи и отображаемые типы должны оставаться псевдонимами типов.
• Сообщения об ошибках и при наведении курсора на редактор могут отображать тип по-разному, что может удивить товарищей по команде, но не меняет поведения.

Внесите изменение в одном целенаправленном запросе на включение, запустите компилятор в строгом режиме и свой набор тестов и избегайте смешивания его с работой над функциями, чтобы рецензенты могли видеть, что больше ничего не изменилось.

Итоги

На вопрос «интерфейс против типа» есть спокойный ответ: они перекрываются для объектов, у каждого есть несколько уникальных способностей, и последовательность важнее, чем выбор. Используйте интерфейсы для форм и типов для всего остального, если ваша команда не предпочитает иное. Чтобы увидеть различия самостоятельно, скопируйте приведенные выше примеры в файл и запустите на нем tsc --noEmit --strict.

Часто задаваемые вопросы

Продолжайте учиться