Interface vs Type di TypeScript: Perbedaan dan Kapan Dipakai

Untuk menjelaskan bentuk sebuah object, interface dan type melakukan tugas yang sama, dan nilai dari yang satu bisa di-assign ke yang lain kalau bentuknya cocok. Perbedaannya ada di pinggiran: type bisa memberi nama pada hal-hal yang tidak bisa dilakukan interface (union, tuple, tipe hasil komputasi), dan interface bisa melakukan beberapa hal yang tidak bisa dilakukan type alias (merging, extends yang diperiksa).

interface PointI {
  x: number;
  y: number;
}

type PointT = {
  x: number;
  y: number;
};

const a: PointI = { x: 1, y: 2 };
const b: PointT = a; // same shape, so they are interchangeable
const c: PointI = b;

function show(p: PointI): string {
  return `(${p.x}, ${p.y})`;
}

console.log(show(b), show(c)); // (1, 2) (1, 2)

TypeScript membandingkan tipe object berdasarkan struktur, jadi nama deklarasinya tidak berpengaruh pada assignability. Berikut daftar tempat pilihan itu benar-benar berpengaruh.

Tabel Perbandingan

Yang Hanya Bisa Dilakukan type

Apa pun yang bukan satu bentuk object membutuhkan type alias:

type Status = "idle" | "loading" | "done";                   // union of literals
type Coordinates = [lat: number, lng: number];               // tuple
type Handler = (event: string) => void;                      // function type
type ID = string | number;                                   // union of primitives
type Flags<T> = { [K in keyof T]: boolean };                 // mapped type
type ElementOf<T> = T extends readonly (infer U)[] ? U : T;  // conditional type

const current: Status = "loading";
const here: Coordinates = [51.5, -0.12];
const onSave: Handler = (e) => console.log("saved:", e);
const flags: Flags<{ dark: string; beta: number }> = { dark: true, beta: false };
const first: ElementOf<string[]> = "a";

onSave(current);
console.log(here, flags, first);
// saved: loading
// [ 51.5, -0.12 ] { dark: true, beta: false } a

Tidak satu pun dari ini bisa ditulis dengan interface (dua yang terakhir dibahas di mapped type dan conditional type). Inilah alasan praktis kenapa setiap codebase pada akhirnya memakai type di suatu tempat, apa pun yang dipakainya untuk bentuk object.

Yang Hanya Bisa Dilakukan interface: Declaration Merging

Dua deklarasi interface dengan nama yang sama di scope yang sama akan digabung menjadi satu. Dua deklarasi type dengan nama yang sama menghasilkan error TS2300, Duplicate identifier.

interface Settings {
  theme: string;
}
interface Settings {
  fontSize: number;
}
const s: Settings = { theme: "dark", fontSize: 14 }; // needs both

type Options = { a: number };
type Options = { b: number }; // error TS2300: Duplicate identifier 'Options'.

Merging adalah cara tipe library diperluas dari luar: menambahkan properti ke Window global, ke Request milik Express, atau ke tipe theme sebuah library. Kalau kamu memublikasikan tipe yang mungkin perlu diperluas oleh penggunanya, pakai interface. Di kode aplikasimu sendiri, merging yang tidak disengaja (dua file script yang mendeklarasikan nama interface global yang sama) terjadi diam-diam, kecuali keduanya mendeklarasikan properti yang sama dengan tipe berbeda. Itulah salah satu alasan sebagian tim lebih memilih type.

extends vs Intersection

Interface diperluas dengan extends, type alias dengan &. Hasil keduanya kebanyakan sama, tetapi cara menangani properti yang bertentangan berbeda. extends melaporkan konflik itu di deklarasinya:

// This does not compile: id cannot change from string to number
interface Base {
  id: string;
  name: string;
}

interface Broken extends Base {
  id: number;
}

const x: Broken = { id: 1, name: "a" };
console.log(x);

index.ts(7,11): error TS2430: Interface 'Broken' incorrectly extends interface 'Base'.
  Types of property 'id' are incompatible.
    Type 'number' is not assignable to type 'string'.

Intersection menerima konflik yang sama secara diam-diam dan mengubah propertinya menjadi never (sebuah string yang sekaligus number). Error-nya baru muncul belakangan, ketika kamu mencoba membuat sebuah nilai:

type Base = { id: string; name: string };
type Broken = Base & { id: number }; // no error here

// id is string & number, which is never: no object can satisfy Broken
// @ts-expect-error: Type 'number' is not assignable to type 'never'.
const x: Broken = { id: 1, name: "a" };

console.log("the alias compiled; only using it failed");

Error-nya menunjuk ke object, jauh dari deklarasi yang menyebabkannya. Untuk membangun tipe object dari tipe object lain, extends memberi pesan yang lebih baik.

Index Signature: Perbedaan yang Mudah Terlewat

Type alias untuk tipe object mendapat index signature implisit, jadi bisa dikirim ke tempat yang mengharapkan Record<string, unknown>. Interface tidak. Ini memang disengaja: penjelasan dari tim TypeScript (issue #15300 di repository TypeScript) adalah bahwa interface bisa diperluas oleh deklarasi berikutnya, jadi menyimpulkan index signature untuknya kurang aman, dan mengubah aturan ini sekarang akan merusak terlalu banyak kode.

interface UserI { name: string; age: number }
type UserT = { name: string; age: number };

function logFields(fields: Record<string, unknown>) {
  for (const [key, value] of Object.entries(fields)) {
    console.log(`${key}=${String(value)}`);
  }
}

const t: UserT = { name: "Ada", age: 36 };
const i: UserI = { name: "Alan", age: 41 };

logFields(t); // fine

// @ts-expect-error: Index signature for type 'string' is missing in type 'UserI'.
logFields(i);

logFields({ ...i }); // a spread copy is a fresh object type, so it is accepted

Pemanggilan yang ditandai @ts-expect-error tetap berjalan dan mencetak field milik Alan: aturan ini hanya berlaku saat kompilasi. Inilah penyebab umum error yang membingungkan ketika nilai bertipe interface dikirim ke helper logging, serialisasi, atau query yang bertipe Record<string, ...>. Ubah deklarasi yang satu itu menjadi type, lakukan spread pada nilainya, atau beri tipe parameter helper itu dengan interface atau generic.

Performa dan Pesan Error

Halaman Performance di wiki TypeScript (bagian "Preferring Interfaces Over Intersections") menyarankan interface Foo extends Bar, Baz { ... } dibandingkan type Foo = Bar & Baz & { ... } saat menyusun tipe object. Alasannya: interface adalah satu tipe object datar yang bisa mendeteksi konflik properti, hubungan tipe antar-interface disimpan di cache (intersection secara keseluruhan tidak), dan memeriksa nilai terhadap intersection berarti memeriksa setiap bagiannya sebelum tipe yang sudah diratakan. Perbedaannya terasa di codebase besar dengan banyak tipe hasil komposisi; untuk beberapa bentuk object biasa, kamu tidak akan bisa mengukurnya.

Halaman yang sama juga mencatat bahwa interface ditampilkan dengan lebih baik. Interface ditampilkan dengan namanya saat hover dan di pesan error, sedangkan alias intersection sering dicetak dalam bentuk terurai menjadi bagian-bagiannya, sehingga pesan yang panjang lebih sulit dibaca.

Mana yang Dipakai

Aturan yang bisa diandalkan:

1. Bentuk object: interface. Ia memberi extends yang diperiksa, error yang lebih jelas pada komposisi besar, dan bisa diperluas oleh pengguna library. Ini sesuai dengan pedoman TypeScript handbook: "pakai interface sampai kamu perlu memakai fitur dari type".
2. Semua yang lain: type. Union, tuple, tipe fungsi, tipe literal, dan apa pun yang dibangun dengan mapped type, conditional type, atau template literal type.
3. Pengecualian: pakai type untuk bentuk object yang harus cocok dengan parameter Record<string, ...>, atau kalau kamu memang sengaja ingin mencegah merging.

Memakai type untuk semuanya juga pilihan yang konsisten, dan banyak codebase melakukannya. Mencampur keduanya secara acak adalah satu-satunya pilihan yang perlu dihindari: pembaca jadi bertanya-tanya apakah ada perbedaan yang disengaja.