タイプ ✔ VS インターフェイス ❌: TypeScript でインターフェイスではなくタイプを選択する理由。

私は、インターフェイスではなく常に型を使用する必要があるという解決策に到達しました。その理由を詳しく見てみましょう!!

• インターフェイスではオブジェクトのみを指定できますが、タイプ エイリアスではオブジェクトとその他すべてを指定できます。 単一の Address フィールドがあり、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 型と呼ばれ、アドレスは文字列、または文字列の配列となります。

インターフェースエイリアスを使用すると、このようなことを行うことができます。

• types エイリアスはユーティリティ型を簡単に使用できます。インターフェイスは可能ですが、見栄えが悪くなります。たとえば、ユーザー オブジェクトを考えてみましょう。

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

ここで、ゲスト オブジェクトがあるとします。これはログインされていませんが、いつ作成されたか (最初にページに表示されたか) を確認できます。このシナリオでは、ゲストはユーザーに似ていますが、実際のユーザーではありません。ユーザーのタイプエイリアスのゲストに created_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 という名前を付けるのでしょうか。会社がインターフェイスよりもタイプを好むのであれば、なぜあなたもそうしないのでしょうか? ?

結論

常にインターフェースよりも型を優先します。一部の開発者は、インターフェイスの読み込みが型よりも速いと言っています...しかし、それは過去に起こりました。今ではパフォーマンスに関しては違いはありません。インターフェースが必要になるユースケースがいくつかありますが、常にインターフェースが必要であるという意味ではありません。

以上がタイプ ✔ VS インターフェイス ❌: TypeScript でインターフェイスではなくタイプを選択する理由。の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。