Ngapain Sih Pake TypeScript di React? Ribet Tapi Worth It

Awal mula gue pake TypeScript itu sebenernya bukan karena inisiatif sendiri, tapi karena kepepet. Waktu itu kantor lagi ngembangin dashboard chatbot buat tim CS, dan project-nya udah jalan duluan pake TypeScript. Gue yang baru masuk tim, langsung disodorin codebase penuh .tsx, lengkap dengan tipe-tipe aneh yang bikin kepala gatel. “Ngapain sih harus nulis : string di mana-mana? Emang nggak cukup const aja?” pikir gue waktu itu. Tapi ya karena namanya kerja tim, mau nggak mau harus ikut arus. Dan dari situ, pelan-pelan gue mulai ngerti: ternyata banyak hal yang dulunya bikin deg-degan waktu ngoding, sekarang bisa lebih tenang karena dibantu sama TypeScript.

Pas pertama kali ngeliat error di TypeScript, rasanya pengen bilang: “Apaan sih ini error biru-biru, niat ngoding malah dimarahin terus.” Padahal kode gue jalan di browser, tapi TypeScript tetep ngegas bilang “Property ‘foo’ does not exist on type bla bla bla.” Lah, padahal tadi di JavaScript nggak ada yang komplain tuh. Rasanya kayak punya senior cerewet yang selalu ngecek kerjaan kita — padahal baru ngetik setengah jalan. Tapi lama-lama, gue mulai nyadar, si “senior cerewet” ini sebenernya ngingetin hal-hal yang penting. Bukan buat nyusahin, tapi buat nyelametin.

Masalah di JavaScript (tanpa TS)

Salah satu masalah paling ngeselin di JavaScript itu adalah typo kecil yang nggak ketahuan... sampai akhirnya muncul di runtime. Misalnya kita punya object user, terus kita manggil user.usename (padahal harusnya username). Di JavaScript? Aman-aman aja, nggak ada warning, nggak ada error. Tapi pas ngejalanin, hasilnya undefined, dan tiba-tiba logic kita ngaco. Di situ kadang saya merasa... “kenapa JavaScript baik-baik aja padahal gue udah salah ketik?”

Dengan TypeScript, kejadian kayak gitu langsung ketangkep. Dia bakal bilang: “Bro, property usename nggak ada di object User.” Dan itu kerasa banget pas lagi refactor komponen, rename properti, atau nyambungin data dari API — karena kita jadi tau apa yang valid dan apa yang nggak, sebelum kode dijalanin.

Dulu waktu masih pake JavaScript, nge-passing props ke komponen tuh kayak lempar-lempar bola tanpa aturan. Asal kasih aja title="..." atau data={someObj}, dan komponen bakal semoga ngerti. Tapi masalahnya, kalau props yang dikirim salah — entah typo, atau ngasih tipe yang nggak sesuai — React nggak akan ngeluh. Komponennya mungkin jalan, tapi datanya bisa kacau, atau UI-nya malah nggak muncul. Dan kerennya, lo baru nyadar pas udah buka halaman itu... atau lebih parah lagi: user yang nemu 😅

TypeScript ngubah game-nya total. Begitu lo define props di komponen kayak:

type Props = {
  title: string;
  isActive: boolean;
};

const MyComponent = ({ title, isActive }: Props) => { ... }

Lo nggak bisa asal ngasih title={123} atau isActve={true} (typo dikit doang tuh, tapi fatal). Langsung ditolak sebelum sempat jalan. Dan ini bikin pengalaman ngoding lebih tenang — apalagi pas kerja bareng tim besar. Udah nggak ada drama props nyasar.

Salah satu error paling ngeselin — dan legendaris — di dunia JavaScript adalah: TypeError: undefined is not a function

Gue yakin semua developer JS pasti pernah kena. Biasanya karena kita manggil function yang ternyata... nggak ada. Misalnya:

user.getProfile()

Padahal user ternyata belum kebentuk, atau getProfile itu nggak pernah ada di object-nya. Dan boom — runtime error, page blank, user kebingungan, kita panik buka DevTools. Serunya lagi, ini biasanya baru ketahuan setelah deploy, karena linter pun nggak bisa deteksi.

Nah, dengan TypeScript, kejadian kayak gini bisa dicegah sebelum kejadian. Begitu kita define tipe user:

type User = {
  name: string;
  getProfile: () => void;
};

Kalau getProfile nggak ada atau tipenya salah, langsung dikasih warning. Bahkan kalau kita belum inisialisasi user dengan benar, TS udah mulai cerewet dari awal. Hasilnya? Lebih jarang error misterius pas runtime, dan refactor pun jadi lebih berani karena kita tau semua “kontrak” udah dijaga.

Dulu, tiap kali mau refactor state atau props di React pake JavaScript, rasanya kayak lagi motong kabel bom: salah dikit bisa meledak. Misalnya lo ganti nama props status jadi userStatus, terus lo harus cari di seluruh komponen mana aja yang make. Kadang ada yang kelewat, kadang ada yang typo, dan hasilnya... UI jadi error, tapi nggak ketahuan sampai user komplain.

Itu yang bikin refactor di JavaScript tuh deg-degan. Karena kita nggak punya jaminan semuanya masih nyambung dengan benar — kecuali lo manual cek satu-satu. Tapi sejak pake TypeScript, perasaan deg-degan itu perlahan hilang. Karena begitu lo ubah nama props atau shape dari state, TypeScript langsung nunjukin semua tempat yang kena dampaknya. Kayak punya GPS waktu lagi ngacak-ngacak kode.

Lo bisa confident refactor besar-besaran tanpa rasa was-was. Mau ganti nama prop, pecah jadi custom hook, ubah shape object — selama tipe-nya aman, semuanya ikut aman.

Pertamakali menggunakan (ngoding) Typescript 👨🏻‍💻

Waktu pertama kali beneran ngoding pake TypeScript, pikiran gue cuma satu:
“Kenapa sih harus define semua tipe? Emangnya gue nggak punya kerjaan lain?” 😅

Baru bikin satu komponen kecil aja, udah disuruh nulis type Props = { title: string; onClick: () => void } — padahal di JavaScript bisa langsung gas aja. Awalnya kerasa kayak nambah beban: semuanya harus ditulis eksplisit, dari props, state, sampai return value function. Apalagi kalau ketemu tipe yang kompleks, kayak nested object dari API, itu kayak ngerjain PR matematika.

Tapi ternyata... justru dari situ mulai kelihatan manfaatnya. Pas pake IDE, auto-complete jadi makin akurat. Nggak perlu buka file lain buat inget apa aja isi object-nya. Dan pas lagi develop, setiap ada yang typo atau tipe nggak cocok, langsung dikasih tau — bahkan sebelum browser sempet nunjukin error.

Lama-lama mulai kerasa: effort nulis tipe itu kayak nabung di awal, biar lo nggak bangkrut waktu debug dan refactor nanti.

Manfaat Paling Kerasa di React

Setelah mulai terbiasa, manfaat TypeScript di React tuh makin terasa di tiap sudut. Pertama yang paling obvious: auto-complete props. Lo cukup hover atau ketik props. dan semua field langsung muncul — lengkap sama tipenya. Nggak ada lagi buka tab file sebelah cuma buat ngecek “ini props-nya apa aja ya?”

Terus waktu bikin reducer atau context, biasanya penuh risiko karena shape state-nya bisa berubah dan lo harus tracking secara manual. Tapi dengan TypeScript, semua jadi jauh lebih solid. Misal lo punya action SET_USER, lo bisa define tipe payload-nya, dan setiap kali dispatch, lo bakal dikasih tau kalau payload-nya nggak sesuai. Hasilnya? Logic lebih jelas, bug lebih sedikit.

Satu lagi yang gue suka: shared types antar komponen. Lo bisa bikin satu User type, terus dipake di mana-mana: props, state, API response, bahkan di testing. Jadi semua komponen ngomong dalam “bahasa” yang sama. Nggak ada lagi kasus user.name kadang string, kadang number, kadang undefined — TypeScript langsung nyaring semuanya.

Intinya, makin kompleks project lo, makin berasa TypeScript itu bukan ribet — tapi justru ngebantu lo biar nggak makin ribet.

Tantangan & Tips

Tentu aja, ngoding pake TypeScript nggak selalu mulus. Salah satu tantangan paling umum itu adalah tipe data yang ribet, terutama dari API response yang nested-nya dalam banget. Misalnya, response dari backend ngasih object user.profile.avatar.url, dan kita harus define tipe-nya satu-satu — bisa bikin kepala muter 🤯

Nah, biar nggak kewalahan, ada beberapa cara buat nyiasatinya:

• Gunakan utility types bawaan TypeScript seperti:

  • Partial<T> buat nge-define tipe yang belum lengkap (misalnya form input yang masih kosong).

  • Pick<T, 'field'> buat ambil sebagian field aja dari tipe yang udah ada.

  • Record<K, T> buat bikin object yang key-nya dinamis tapi tetap ketat tipenya.

Ini bisa bantu banget buat bikin kode tetap DRY (Don't Repeat Yourself) dan lebih fleksibel.

• Kalau lo dapet data dari API dan butuh validasi runtime, bisa pake tools kayak zod. Zod bukan cuma bantu parsing dan validasi data, tapi juga bisa auto-generate TypeScript type dari schema yang lo define. Jadi lo dapet validasi dan autocompletion sekaligus. Win-win!

• Dan terakhir, jangan ragu buat ngebuat helper types sendiri. Kadang bikin utility tipe kayak Nullable<T> = T | null atau ApiResponse<T> = { data: T; error?: string } itu bisa nyelametin banyak waktu di jangka panjang.

Penutup

Kalau ditanya “Ngapain sih pake TypeScript di React?”, jawaban jujurnya adalah: emang ribet di awal. Tapi kayak naik motor pakai helm, atau nyetir pakai sabuk pengaman — agak repot, tapi lo tahu itu buat keamanan dan kenyamanan jangka panjang 🛡️

Begitu proyek makin gede, logic makin kompleks, dan komponen makin banyak — TypeScript justru jadi penyelamat. Refactor jadi lebih berani, nge-debug lebih cepat, dan auto-complete jadi sahabat terbaik.

Bonusnya, kalau kerja bareng tim? TypeScript bisa ngurangin miskomunikasi antar dev. Lo cukup define type di satu tempat, dan semua orang langsung tau harus ngasih apa dan nerima apa. Nggak perlu chat panjang di Slack cuma buat nanya "ini props-nya apa aja ya?"

Jadi ya... ribet di awal, tapi worth it banget.
Kalau lo baru mau nyoba, santai aja — nggak harus langsung hardcore. Pelan-pelan kenalan, dan nikmatin prosesnya.