Type Assertion

Memberi Tahu yang Compiler Tidak Tahu

Kadang kamu tahu lebih banyak daripada compiler, misalnya elemen DOM yang pasti ada:

const input = document.getElementById("nama") as HTMLInputElement;
console.log(input.value); // ok, compiler percaya ini input element

Tanpa assertion, getElementById mengembalikan HTMLElement | null dan .value error. Assertion mengatakan: "percayalah, ini input".

Assertion Bukan Konversi

Ini kesalahpahaman paling umum. Assertion tidak mengubah data saat runtime:

const x = "123" as number;
console.log(typeof x); // "string"! tetap string, tidak jadi number

as hanya mengubah cara compiler memandang nilai, bukan nilainya. Kalau butuh konversi sungguhan, pakai Number("123").

Non-null Assertion: Tanda Seru

function fokuskan(id: string) {
  const el = document.getElementById(id);
  el!.focus(); // "aku yakin el tidak null"
}

Tanda ! membuang null dan undefined dari tipe. Praktis, tapi berbahaya: kalau ternyata null, error runtime Cannot read properties of null yang justru ingin dihindari TypeScript.

Aturan Pakai yang Sehat

1. Boleh: menjembatani celah yang compiler tidak bisa tahu (DOM API, JSON.parse yang strukturnya kamu jamin).
2. Hindari: memakai as untuk membungkam error yang tidak kamu pahami. Itu seperti mematikan alarm kebakaran karena berisik.
3. Alternatif dulu: narrowing (if), type guard, atau perbaiki tipe sumbernya. Assertion adalah jalan terakhir, bukan pertama.

// buruk: menutupi masalah
const user = dapatkanData() as Pengguna;

// baik: verifikasi dulu
const data: unknown = dapatkanData();
if (adalahPengguna(data)) {
  // pakai data sebagai Pengguna dengan aman
}

Catatan teknis: Assertion ganda ("x" as unknown as number) adalah code smell serius. Melewati unknown untuk memaksa dua tipe yang tidak berhubungan artinya kamu sedang melawan sistem tipe, bukan memakainya. Kalau sampai butuh ini, kemungkinan besar desain tipenya yang salah dan perlu diperbaiki dari akarnya.