Type ✔ Vs Interface ❌: TypeScript에서 인터페이스 대신 Type을 선택해야 하는 이유.

저는 항상 인터페이스보다 유형을 사용해야 한다는 해결책을 찾았습니다. 그 이유를 분석해보자!!

• 인터페이스는 객체만 지정할 수 있지만 유형 별칭은 객체와 그 밖의 모든 것을 지정할 수 있습니다. 단일 주소 필드가 있고 유형을 사용하여 다음과 같이 해당 유형을 정의한다고 가정해 보겠습니다.

type Address = string;
const address: Address = '123 Hallway'

그러나 다음과 같은 인터페이스로는 이러한 작업을 수행할 수 없습니다.

interface Address = string; //error
const address: Address = '123 Hallway'

인터페이스 별칭은 객체만 정의할 수 있기 때문입니다. 다음과 같은 인터페이스를 사용하려면 구조를 완전히 변경해야 합니다.

interface Address {
    address: string;
}
const address: Address = {
    address: '12 3 Hallway'
}

인터페이스의 첫 번째 문제입니다.

• 유형 별칭은 Union 유형을 정의할 수 있지만 인터페이스 별칭은 다음을 정의할 수 없습니다. 사용자는 여러 개의 주소 또는 단일 주소를 가질 수 있습니다.

type Address = string | string[] ;
const address: Address = '123 Hallway'
const newAddress: Address= ['123 Hallway', 'Flag Plaza']

문자열 | string[]은 Union 유형이라고 하며 주소는 문자열 또는 문자열 배열일 수 있습니다.

인터페이스 별칭을 사용하면 이러한 작업을 수행할 수 있습니다.

• 유형 별칭은 유틸리티 유형을 쉽게 사용할 수 있습니다. 인터페이스는 가능하지만 보기 흉해 보일 것입니다. 예를 들어 사용자 객체를 고려해보세요:

type User = {
    name: string;
    age: number;
    created_at: Date;
}

이제 로그인되지 않았지만 언제 생성되었는지(페이지에 처음으로 접속했는지) 확인할 수 있는 게스트 개체가 있다고 가정해 보겠습니다. 이 시나리오에서 게스트는 사용자와 유사하지만 실제 사용자는 아닙니다. User In 유형 별칭의 Guest에서 Create_at 속성을 갖고 싶습니다.

     type Guest = Omit<User, 'name' | 'age'>

기술적으로 인터페이스를 사용하면 가능하지만 작동 방식을 확인하세요.

type Guest extends Omit<User, 'name' | 'age'> {}

작동은 되지만 구문이 보기 흉하지 않나요?

• 튜플을 설명해야 하는 경우도 있습니다. 유형 별칭으로 설명하는 방법은 다음과 같습니다.

type Address = [string, number, string] ;
const address: Address = ['Hallway', 2, 'Abdul Plaza']

인터페이스를 사용하여 어떻게 하는지 살펴보세요.

type Address extends Array<number | string> {
    0: string
    1: number;
    2: string;
}

const address: Address = ['Hallway', 2, 'Abdul Plaza']

또 이상한 구문이군요.

• 유형 별칭을 사용하면 유형을 매우 쉽게 추출할 수 있습니다.

const love_bonito ={
    level: 1,
    store_id: 'scad_12hdedhefgfeaa',
    country: ['US','PK','IND'],
    user: {
        user_id: "blah',
        username: 'nishat',
        likes: 421,
    },
};

// let's extract type for love_bonito
type LoveBonito = typeOf love_bonito;

// or even something inside love_bonito
type User = typeOf love_bonito.user;  

이에 대한 보너스는 현재 레벨이 항상 1이고 다른 것이 없다면 그렇게 할 수도 있다는 것입니다.

const love_bonito ={
    level: 1,
    store_id: 'scad_12hdedhefgfeaa',
    country: ['US','PK','IND'],
    user: {
        user_id: "blah';
        username: 'nishat';
        likes: 421;
    },
} as const

// let's extract type for love_bonito
type LoveBonito = typeOf love_bonito

// or even something inside love_bonito
type User = typeOf love_bonito.user

이제 레벨은 숫자가 아닌 1로 추론됩니다.

• 인터페이스 별칭을 사용하면 인터페이스를 다시 선언할 수 있습니다.

interface Home {
    rooms: number;
    light_bulbs: 12;
    rented_to: "Abu Turab";
}

interface Home {
   fans: 16;
}

// final type 

interface Home {
    rooms: 3;
    light_bulbs: 12;
    rented_to: "Abu Turab";
    fans: 16;
}

유형 별칭을 다시 선언할 수 없습니다. "아! 셰라즈, 이게 인터페이스의 장점이구나"라고 생각하실 수도 있겠지만 사실은 그렇지 않습니다!!!

코드베이스 전체에 걸쳐 동일한 식별자를 가진 선언이 여러 개 있으면 혼란스러울 것 같습니다. 정말 헷갈리는 것 같아요.

팀과 함께 작업하고 객체 유형(인터페이스로 선언된 유형)을 알고 있었지만 팀의 누군가가 이를 다시 선언하고 변경한다고 가정해 보겠습니다.

그러나 유형 별칭을 사용하면 이 문제도 해결됩니다. 유형을 다시 선언하면 오류가 발생합니다

중복 식별자

• 라이브러리 이름이 INTERFACESCRIPT가 아닌 TYPESCRIPT입니다. 펑키할 수도 있지만 회사에서는 왜 IBTERFACESCRIPT가 아닌 라이브러리 이름을 TYPESCRIPT로 선택했을까요? 회사가 인터페이스보다 유형을 선호한다면 당신은 어떻습니까? ?

결론

항상 인터페이스보다 유형을 선호하세요. 일부 개발자는 인터페이스가 유형보다 빠르게 로드된다고 말합니다. 하지만 과거에는 그런 일이 있었습니다. 이제는 성능면에서 차이가 없습니다. 인터페이스가 필요할 수 있는 일부 사용 사례가 있지만 이것이 항상 인터페이스해야 한다는 의미는 아닙니다.

위 내용은 Type ✔ Vs Interface ❌: TypeScript에서 인터페이스 대신 Type을 선택해야 하는 이유.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!