# 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:

```typescript
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:

```typescript
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`:

```typescript
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`](http://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`](https://github.com/colinhacks/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.