Coba perhatiin dua potongan kode ini:

index.tstypescript

let umur: number = 25;

let nama: string = "Budi";

2 baris•49 chars

UTF-8•Spaces: 4

index.tstypescript

let umur = 25;

let nama = "Budi";

2 baris•33 chars

UTF-8•Spaces: 4

Keduanya sama-sama valid di TypeScript, dan keduanya sama-sama aman. Bedanya, versi kedua gak perlu nulis anotasi tipe sama sekali, tapi TypeScript tetap tahu

PLAINTEXT Snippetplaintext

umur

1 baris•4 chars

UTF-8•Spaces: 4

itu

PLAINTEXT Snippetplaintext

number

1 baris•6 chars

UTF-8•Spaces: 4

dan

PLAINTEXT Snippetplaintext

nama

1 baris•4 chars

UTF-8•Spaces: 4

itu

PLAINTEXT Snippetplaintext

string

1 baris•6 chars

UTF-8•Spaces: 4

. Ini yang disebut type inference, kemampuan TypeScript buat nebak tipe data sendiri berdasarkan nilai yang kamu kasih.

Banyak pemula yang belum ngeh soal ini, akhirnya kebiasaan nulis anotasi tipe di semua tempat, padahal banyak yang sebenarnya gak perlu. Efeknya, kode jadi lebih panjang dari yang seharusnya, dan malah kelihatan lebih ribet dibanding manfaatnya.

Gimana Sebenarnya Type Inference Bekerja

TypeScript nebak tipe data dari beberapa sumber, tergantung konteksnya. Yang paling gampang adalah dari nilai literal yang kamu tulis langsung.

index.tstypescript

let harga = 50000; // TypeScript tahu ini number

let aktif = true; // TypeScript tahu ini boolean

let daftarNama = ["Andi", "Budi"]; // TypeScript tahu ini string[]

3 baris•164 chars

UTF-8•Spaces: 4

Selain dari nilai literal, TypeScript juga bisa nebak tipe dari return value sebuah fungsi, tanpa kamu perlu nulis tipe return-nya secara eksplisit.

index.tstypescript

function tambah(a: number, b: number) {

  return a + b;

}

// TypeScript otomatis tahu return type-nya number

4 baris•108 chars

UTF-8•Spaces: 4

Yang menarik, meskipun kamu gak nulis

PLAINTEXT Snippetplaintext

: number

1 baris•8 chars

UTF-8•Spaces: 4

setelah parameter closing di atas, TypeScript tetap bisa nebak dengan benar karena dia ngeliat tipe dari

PLAINTEXT Snippetplaintext

1 baris•1 chars

UTF-8•Spaces: 4

dan

PLAINTEXT Snippetplaintext

1 baris•1 chars

UTF-8•Spaces: 4

, terus ngikutin gimana operasi

PLAINTEXT Snippetplaintext

1 baris•1 chars

UTF-8•Spaces: 4

bekerja di antara dua

PLAINTEXT Snippetplaintext

number

1 baris•6 chars

UTF-8•Spaces: 4

Contextual Typing, Nebak Tipe dari "Situasi Sekitar"

Selain nebak dari nilai langsung, TypeScript juga punya kemampuan yang disebut contextual typing, yaitu nebak tipe berdasarkan konteks di mana kode itu dipakai, bukan cuma dari nilainya sendiri.

Contoh paling gampang ada di event handler:

index.tstypescript

window.addEventListener("click", function (event) {

  console.log(event.button); // TypeScript tahu event itu MouseEvent

});

3 baris•124 chars

UTF-8•Spaces: 4

Perhatiin, kamu gak nulis tipe apa-apa buat parameter

PLAINTEXT Snippetplaintext

event

1 baris•5 chars

UTF-8•Spaces: 4

, tapi TypeScript tetap tahu itu

PLAINTEXT Snippetplaintext

MouseEvent

1 baris•10 chars

UTF-8•Spaces: 4

, lengkap dengan semua propertinya kayak

PLAINTEXT Snippetplaintext

button

1 baris•6 chars

UTF-8•Spaces: 4

PLAINTEXT Snippetplaintext

clientX

1 baris•7 chars

UTF-8•Spaces: 4

, dan seterusnya. Ini kejadian karena TypeScript udah tahu signature dari

PLAINTEXT Snippetplaintext

addEventListener

1 baris•16 chars

UTF-8•Spaces: 4

, dan dia "nurunin" tipe yang sesuai ke parameter fungsi callback kamu berdasarkan konteks itu.

Ini juga kejadian pas kamu kerja sama array method kayak

PLAINTEXT Snippetplaintext

map

1 baris•3 chars

UTF-8•Spaces: 4

atau

PLAINTEXT Snippetplaintext

filter

1 baris•6 chars

UTF-8•Spaces: 4

index.tstypescript

const angka = [1, 2, 3];

const kuadrat = angka.map((n) => n * n);

// TypeScript tahu n itu number, tanpa perlu ditulis manual

3 baris•125 chars

UTF-8•Spaces: 4

Kapan Inference Bisa Menyesatkan

Type inference emang membantu banget, tapi bukan berarti dia selalu sempurna. Ada beberapa kasus umum di mana inference justru bisa bikin bug yang gak kelihatan di awal.

Array Kosong

index.tstypescript

let daftar = [];

daftar.push("a");

daftar.push(1);

3 baris•50 chars

UTF-8•Spaces: 4

Coba tebak, tipe apa yang TypeScript kasih ke

PLAINTEXT Snippetplaintext

daftar

1 baris•6 chars

UTF-8•Spaces: 4

di baris pertama? Karena array-nya kosong, TypeScript gak punya cukup informasi buat nebak isinya bakal berupa apa, jadi dia kasih tipe

PLAINTEXT Snippetplaintext

any[]

1 baris•5 chars

UTF-8•Spaces: 4

. Ini artinya,

PLAINTEXT Snippetplaintext

daftar.push("a")

1 baris•16 chars

UTF-8•Spaces: 4

dan

PLAINTEXT Snippetplaintext

daftar.push(1)

1 baris•14 chars

UTF-8•Spaces: 4

sama-sama gak akan dianggap error, padahal mungkin maksud kamu awalnya cuma buat nampung angka aja.

Solusinya, kasih anotasi eksplisit dari awal kalau kamu udah tahu isinya bakal apa:

index.tstypescript

let daftar: number[] = [];

daftar.push(1); // aman

daftar.push("a"); // Error, string gak bisa masuk ke number[]

3 baris•112 chars

UTF-8•Spaces: 4

Objek yang Bentuknya Berubah Seiring Waktu

index.tstypescript

let user = { nama: "Andi" };

user.umur = 25; // Error, properti umur gak ada di tipe awal

2 baris•89 chars

UTF-8•Spaces: 4

Ini sering bikin bingung pemula. Kenapa error padahal cuma nambahin properti baru? Jawabannya, pas kamu nulis

PLAINTEXT Snippetplaintext

let user = { nama: "Andi" }

1 baris•27 chars

UTF-8•Spaces: 4

, TypeScript langsung nebak tipe

PLAINTEXT Snippetplaintext

user

1 baris•4 chars

UTF-8•Spaces: 4

itu

PLAINTEXT Snippetplaintext

{ nama: string }

1 baris•16 chars

UTF-8•Spaces: 4

, dan tipe ini "dikunci" dari awal. TypeScript gak otomatis ngizinin kamu nambahin properti baru setelahnya, karena secara default dia nganggep bentuk objek itu tetap dari awal sampai akhir.

Solusinya, definisiin bentuk lengkap dari awal, entah lewat interface atau langsung di deklarasi:

index.tstypescript

interface User {

  nama: string;

  umur?: number;

}

let user: User = { nama: "Andi" };

user.umur = 25; // aman

7 baris•111 chars

UTF-8•Spaces: 4

Best Common Type yang Kadang Terlalu Luas

Kalau kamu bikin array yang isinya campuran beberapa tipe, TypeScript bakal nyari "best common type", alias tipe gabungan yang paling masuk akal buat nampung semuanya.

index.tstypescript

let campuran = [1, "dua", true];

// TypeScript nebak tipe: (string | number | boolean)[]

2 baris•88 chars

UTF-8•Spaces: 4

Ini sebenarnya udah bener secara teknis, tapi kadang terlalu luas buat kebutuhan kamu. Kalau kamu sebenarnya cuma pengen array angka aja dan yang lain itu kesalahan input, inference kayak gini justru bisa nutupin bug yang sebenarnya harusnya ketahuan dari awal.

Jadi, Kapan Sebaiknya Tetap Nulis Anotasi Manual?

Aturan umumnya, biarin TypeScript nebak sendiri kalau nilainya udah jelas dan gak ambigu, kayak variabel lokal dengan nilai langsung, atau return value fungsi yang sederhana. Tapi ada beberapa situasi di mana nulis anotasi eksplisit tetap lebih baik, meskipun secara teknis gak wajib.

Parameter fungsi, karena TypeScript gak bisa nebak tipe parameter dari mana pun kalau kamu gak kasih tahu:

index.tstypescript

function sapa(nama) {

// Error di strict mode, parameter 'nama' implisit any

  return `Halo, ${nama}`;

}

4 baris•106 chars

UTF-8•Spaces: 4

Return type fungsi publik yang dipakai di banyak tempat, biar ada "kontrak" yang jelas dan gak berubah tanpa sengaja pas kamu refactor isi fungsinya.

Array atau objek kosong yang bakal diisi belakangan, kayak contoh

PLAINTEXT Snippetplaintext

daftar: number[] = []

1 baris•21 chars

UTF-8•Spaces: 4

di atas.

Variabel yang emang sengaja fleksibel di awal, misalnya state di komponen UI yang awalnya

PLAINTEXT Snippetplaintext

null

1 baris•4 chars

UTF-8•Spaces: 4

tapi nanti bisa jadi objek tertentu.

index.tstypescript

let selectedUser: User | null = null;

1 baris•37 chars

UTF-8•Spaces: 4

Kalau kamu gak kasih anotasi di kasus terakhir ini, TypeScript bakal nganggep

PLAINTEXT Snippetplaintext

selectedUser

1 baris•12 chars

UTF-8•Spaces: 4

selamanya bertipe

PLAINTEXT Snippetplaintext

null

1 baris•4 chars

UTF-8•Spaces: 4

, dan kamu gak bakal bisa assign objek

PLAINTEXT Snippetplaintext

User

1 baris•4 chars

UTF-8•Spaces: 4

ke variabel itu nanti.

Kesimpulan

Type inference itu salah satu fitur yang bikin TypeScript kerasa gak seribet yang dibayangin orang pas pertama kali denger "bahasa dengan tipe statis". Kamu gak perlu nulis tipe di setiap baris, karena TypeScript udah cukup pinter buat nebak sendiri di banyak kasus. Tapi penting buat tahu di titik mana inference bisa menyesatkan, kayak array kosong, objek yang bentuknya berubah, atau best common type yang kelewat luas, biar kamu tahu kapan harus turun tangan dan nulis anotasi manual.

Di artikel selanjutnya, kita bakal masuk ke union, intersection, dan discriminated union, salah satu fitur paling kuat di TypeScript buat memodelkan data yang punya banyak kemungkinan bentuk, kayak state loading, success, dan error di aplikasi nyata.

Type Inference, Kapan TypeScript Udah Cukup Pinter dan Kapan Perlu Dibantu

TypeScript Fundamentals

Gimana Sebenarnya Type Inference Bekerja

Contextual Typing, Nebak Tipe dari "Situasi Sekitar"

Kapan Inference Bisa Menyesatkan

Array Kosong

Objek yang Bentuknya Berubah Seiring Waktu

Best Common Type yang Kadang Terlalu Luas

Jadi, Kapan Sebaiknya Tetap Nulis Anotasi Manual?

Kesimpulan

Timur Dian Radha Sejati

Punya Masalah Arsitektur atau Ingin Membangun Sistem yang Benar?

Artikel Rekayasa Terkait

Utility Types yang Wajib Diketahui Setiap Developer TypeScript

Generics, dari Dasar sampai Constraint

Union, Intersection, dan Discriminated Union, Cara Memodelkan Data yang Punya Banyak Kemungkinan Bentuk