typeの方が柔軟で、現代のTypeScript開発では主流
TypeScript開発ではtypeの方が柔軟で、できることが多いため現代では主流です。
以下はtypeとinterfaceの比較表です。
これを見るとinterfaceよりもtypeのほうが優れていることがわかりますね。
| 比較項目 | type | interface |
| ユニオン・タプル定義 | ✅ 可能 | ❌ 不可 |
| 条件付き型・Mapped型 | ✅ 可能 | ⚠️ 限定的 |
| 再利用性（extends, &） | ✅ &で複数型を簡単合成 | ⚠️ extendsで継承 |
| マージ | ✅ 不可なので間違ってマージされる可能性なし | ❌️ 可能なので間違ってマージされる可能性あり |
| IDE補完の安定性 | ✅ 安定 | ❌ 不安定 |
| ReactのProps定義など | ✅ よく使われる | ⚠️ 使えるが冗長になりがち |
この中でも「マージ」は複数人で作業していると、型の追加やGitのマージ、コンフリクト解消などで意図せず発生する可能性があるため、かなり大きなデメリットです。
// 以下のUserはマージされるためエラーにならない
interface User {
id: number
name: string
}
interface User {
id: number
name: string
role?: string
}
const user: User = {
id: 1,
name: '山田太郎',
}
console.log(user)もしも、あなたの会社で「TypeScriptでは基本的にinterfaceを使用する」というおかしなルールがある場合は、必ずESLintルールでマージを検出して警告が表示されるようにしたほうが良いです。
export default [
{
rules: {
'@typescript-eslint/no-redeclare': ['error', { ignoreDeclarationMerge: false }],
},
},
]interface派が主張するパフォーマンスについて
interface派の人はtypeよりもコンパイルが速いことなどを理由に、基本的にはinterfaceを使うべきだと主張する人が多いです。
- interfaceは遅延評価でTypeScript の型システムのネイティブ構造なのでコンパイルが速い
- typeは即時評価で構文的には「型エイリアス」なのでコンパイルが遅い
しかし、interfaceかtypeの違いで速度面の差を体感できるのは、かなりの大規模プロジェクトに限られるため、世の中の半分以上を占める中小規模プロジェクトではinterfaceかtypeの違いで大きな速度差を体感することは少ないです。
また、TypeScriptの開発チーム自身も「パフォーマンスを理由にinterfaceを選ぶべき」とは明言していません。
むしろ重要なのは「わかりやすさ」、「可読性」、「柔軟性」です。
typeは即時評価なので、型をマウスオーバーすれば、どのような型か詳細が表示されます。
しかし、interfaceは遅延評価なので、前述のようなコードの場合はマウスオーバーしても型の詳細が表示されないので、非常に不便です。
また、TypeScriptでは継承がよく使用されますが、typeだと以下のように「&」を使用して簡潔に書けますが、interfaceだとextendsを使用するため少し長くなります。
type User = {
id: number
name: string
}
type Admin = User & {
role: 'admin' | 'user'
}
const admin: Admin = {
id: 1,
name: '山田花子',
role: 'user'
}interface User {
id: number
name: string
}
interface Admin extends User {
role: 'admin' | 'user'
}
const admin: Admin = {
id: 2,
name: '田中太郎',
role: 'user'
}この場合もinterfaceの場合はマウスオーバーしても型の詳細が表示されません。
まとめ
- TypeScriptでは柔軟性・可読性・保守性の観点からinterfaceよりもtypeを使うのが主流
- コンパイル時の速度差を体感できるのは非常に大規模なプロジェクトに限られる
- typeのほうが即時評価されるため、エディタ上でマウスオーバーした際に詳細な型情報が表示されるのでコーディングしやすい
