Niewiele pytań dotyczących TypeScriptu wywołuje tyle dyskusji, co Interfejs TypeScriptu a typ. Wiele artykułów wymienia różnice, które kiedyś miały znaczenie w starszych wersjach, ale są teraz nieaktualne. Zamiast powtarzać twierdzenia, przetestowaliśmy je.

Napisaliśmy jeden plik ćwiczący każdą różnicę i sprawdziliśmy go w TypeScript 5.6.3 w trybie ścisłym. Błędy kompilatora cytowane poniżej pochodzą z tego uruchomienia. Zachowanie może się zmieniać między wersjami, więc sprawdź wersję TypeScript, z której korzysta Twój projekt. Jeśli dopiero zaczynasz przygodę z tym językiem, zacznij od naszego samouczka TypeScript dla początkujących.

Krótka odpowiedź

interface opisuje kształt obiektu, który można przedłużyć lub ponownie otworzyć. Alias ​​type nadaje nazwę dowolnemu typowi, w tym obiektom, uniom, krotkom i typom funkcji. Tam, gdzie oba mogą działać, różnica polega głównie na stylu.

Gdzie są takie same

Te dwie deklaracje opisują identyczne kształty:

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 używa typowania strukturalnego, co oznacza, że porównuje kształty, a nie nazwy. Dlatego User można bez problemu przypisać do UserAlias. Obydwa obsługują opcjonalne właściwości, readonly właściwości, metody i sygnatury indeksów.

Interfejs vs typ obok siebie

Co może zrobić tylko typ

Wiele przydatnych typów w ogóle nie jest kształtami obiektów i tylko alias typu może je nazwać:

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

Typy unii należą do najcenniejszych funkcji TypeScriptu, ponieważ kompilator odrzuca wówczas każdą wartość spoza listy:

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

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

Wychwytuje literówki i nieaktualne wartości w czasie kompilacji, zanim trafią one do produkcji.

Łączenie deklaracji

Jeśli dwukrotnie zadeklarujesz interfejs o tej samej nazwie, TypeScript połączy je w jeden:

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

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

Spróbuj tego samego z aliasem typu, a kompilator odmawia:

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

// error TS2300: Duplicate identifier 'Config'.

Scalanie to sposób, w jaki biblioteki pozwalają rozszerzać swoje typy. Na przykład możesz dodać niestandardową właściwość do interfejsu globalnego Window lub do obiektu żądania struktury bez modyfikowania biblioteki. To naprawdę przydatne.

Drugą stroną jest to, że połączenie może nastąpić przez przypadek. Jeśli dwa pliki w projekcie zadeklarują interfejs o tej samej nazwie w tym samym zakresie, zostaną one po cichu połączone, co może być mylące. Alias ​​typu powoduje, że kolizja staje się zamiast tego błędem.

rozciąga się a przecina

Oba pozwalają budować na istniejącym typie:

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

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

W przypadku zgodnych właściwości wynik jest taki sam. Różnica pojawia się w przypadku konfliktu. Gdy interfejs próbuje w sposób niezgodny zmienić typ właściwości, kompilator natychmiast to zgłasza:

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

Skrzyżowanie nie narzeka, gdy jest zadeklarowane. Zamiast tego właściwość powodująca konflikt staje się never, typem, którego nie może mieć żadna wartość. Błąd pojawia się dopiero później, gdy spróbujesz go użyć:

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

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

Ten późniejszy błąd jest bardziej zagmatwany, ponieważ odwraca uwagę od rzeczywistego błędu. Jest to jeden z praktycznych powodów, dla których warto preferować extends podczas tworzenia typów obiektów.

Zajęcia i narzędzia

Klasa może obiecać dopasowanie kształtu za pomocą implements i działa to z interfejsem lub aliasem typu obiektu:

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

To skompilowało się bez błędów. Zauważ, że implements sprawdza tylko, czy klasa jest zgodna. Nie dodaje żadnych właściwości ani kodu. Klasa nie może zaimplementować typu unii, ponieważ nie ma jednego pasującego kształtu.

Tylko do odczytu i typy narzędzi

Typy narzędzi, takie jak Readonly, Partial, Pick i Omit działają zarówno z interfejsami, jak i aliasami. Wynikiem jest nowy typ, którego nazwa zwykle zawiera alias typu:

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

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

Pamiętaj, że readonly to tylko kontrola w czasie kompilacji. W czasie wykonywania obiektem jest zwykły JavaScript i nadal można go zmienić za pomocą kodu omijającego typy.

Wydajność kompilatora

Własne wskazówki dotyczące wydajności zespołu TypeScript sugerują preferowanie interfejsów korzystających z extends zamiast dużych skrzyżowań, ponieważ kompilator może wydajniej buforować relacje interfejsów. W małych i średnich projektach raczej nie zauważysz żadnej różnicy. Może to mieć znaczenie w przypadku bardzo dużych baz kodu z głęboko skomponowanymi typami. Sami tego nie mierzyliśmy.

Którego powinieneś użyć?

Powszechnie stosowaną regułą, zgodną ze wskazówkami zawartymi w podręczniku TypeScript, jest:

• Użyj interface w przypadku kształtów obiektów, zwłaszcza publicznych interfejsów API i wszystkiego, co implementują klasy lub inne mogą rozszerzać.
• Użyj type w przypadku unii, krotek, typów funkcji oraz typów mapowanych i obliczanych.

Niektóre zespoły po prostu używają type wszędzie i to również działa dobrze. Najważniejsza jest spójność, więc wybierz konwencję, zapisz ją w swoim przewodniku po stylu i pozwól, aby linter ją egzekwował. Może to zrobić reguła ESLint consistent-type-definitions z TypeScript-eslint.

Typowe błędy

• Niekończąca się debata. Obydwa są dobre dla obiektów, więc ustal raz regułę i idź dalej.
• Przypadkowe połączenie. Ponowne użycie nazwy interfejsu w tym samym zakresie powoduje ich ciche połączenie.
• Sprzeczne skrzyżowania. Tworzą never typy z mylącymi błędami później.
• Ufanie typom w czasie wykonywania. Są one usuwane, więc sprawdź dane zewnętrzne.
• Użycie any do wyciszenia błędów. Wyłącza sprawdzanie. Wybierz unknown i zawęź go.

Przełączanie między nimi w istniejącej bazie kodu

Zmiana interface na type lub odwrotnie jest zwykle bezpieczna w przypadku zwykłych kształtów obiektów, ponieważ TypeScript porównuje typy według ich struktury, a nie nazw. Przed zmianą należy jeszcze sprawdzić kilka rzeczy:

• Konwersja interfejsu na alias typu usuwa łączenie deklaracji, więc każda druga deklaracja o tej samej nazwie staje się błędem zduplikowanego identyfikatora.
• Konwersja aliasu typu na interfejs działa tylko w przypadku kształtów obiektów. Unie, krotki i typy mapowane muszą pozostać aliasami typów.
• Komunikaty o błędach i kursory edytora mogą wyświetlać typ w inny sposób, co może zaskoczyć członków drużyny, ale nie zmienia zachowania.

Wprowadź zmianę w jednym skupionym żądaniu ściągnięcia, uruchom kompilator w trybie ścisłym i w zestawie testów i unikaj mieszania tego z pracą nad funkcjami, aby recenzenci mogli zobaczyć, że nic więcej się nie zmieniło.

Podsumowanie

Pytanie dotyczące interfejsu a typu ma spokojną odpowiedź: pokrywają się one w przypadku obiektów, każdy ma kilka unikalnych zdolności, a spójność jest ważniejsza niż wybór. Użyj interfejsów dla kształtów i typów do wszystkiego innego, chyba że Twój zespół woli inaczej. Aby samemu zobaczyć różnice, skopiuj powyższe przykłady do pliku i uruchom na nim tsc --noEmit --strict.

Najczęstsze pytania

Ucz się dalej