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 핸드북의 지침에 따라 널리 사용되는 규칙은 다음과 같습니다.

• 객체 모양, 특히 공용 API와 클래스가 구현하거나 다른 클래스가 확장할 수 있는 모든 항목에는 interface을 사용하세요.
• 합집합, 튜플, 함수 유형, 매핑 또는 계산 유형에는 type을 사용하세요.

일부 팀에서는 어디에서나 단순히 type을 사용하는데 그것도 잘 작동합니다. 가장 중요한 것은 일관성이므로 규칙을 선택하고 스타일 가이드에 작성한 다음 Linter가 이를 시행하도록 하세요. typescript-eslint의 ESLint consistent-type-definitions 규칙이 이를 수행할 수 있습니다.

일반적인 실수

• 끝없는 논쟁. 둘 다 객체에 적합하므로 규칙을 한 번 정하고 다음으로 넘어갑니다.
• 실수로 인한 병합. 동일한 범위에서 인터페이스 이름을 재사용하면 자동으로 결합됩니다.
• 충돌하는 교차로. 나중에 혼란스러운 오류가 있는 never 유형을 만듭니다.
• 런타임에 유형을 신뢰합니다. 해당 유형은 지워지므로 외부 데이터의 유효성을 검사합니다.
• any를 사용하여 오류를 침묵시킵니다. 검사를 끕니다. unknown을 선호하고 범위를 좁힙니다.

기존 코드베이스에서 이들 사이를 전환

interface을 type로 변경하거나 그 반대로 변경하는 것은 일반적으로 일반 개체 모양에 안전합니다. TypeScript는 이름이 아닌 구조를 기준으로 유형을 비교하기 때문입니다. 전환하기 전에 확인해야 할 몇 가지 사항은 다음과 같습니다.

• 인터페이스를 유형 별칭으로 변환하면 선언 병합이 제거되므로 동일한 이름을 가진 두 번째 선언은 중복 식별자 오류가 됩니다.
• 유형 별칭을 인터페이스로 변환하는 것은 객체 모양에만 작동합니다. 공용체, 튜플 및 매핑된 유형은 유형 별칭으로 유지되어야 합니다.
• 오류 메시지와 편집기 마우스 오버는 유형을 다르게 표시할 수 있으며, 이는 팀원을 놀라게 할 수 있지만 동작을 바꾸지는 않습니다.

하나의 집중된 풀 요청으로 변경하고, 엄격 모드와 테스트 스위트에서 컴파일러를 실행하고, 기능 작업과 혼합하지 않도록 하여 검토자가 다른 변경 사항이 없음을 확인할 수 있도록 하세요.

마무리

인터페이스 대 유형 질문에 대한 답은 차분합니다. 객체에 대해 중복되고 각각 고유한 능력이 있으며 선택보다 일관성이 더 중요합니다. 팀에서 달리 선호하지 않는 한, 다른 모든 것에는 모양과 유형에 대한 인터페이스를 사용하십시오. 차이점을 직접 확인하려면 위의 예를 파일에 복사하고 tsc --noEmit --strict을 실행하세요.

자주 묻는 질문

계속 학습하세요