Kenapa Aku Pindah ke Strict Mode TypeScript di Next.js dan Gimana Itu Ngubah Cara Aku Ngoding

Kenapa Aku Pindah ke Strict Mode TypeScript di Next.js dan Gimana Itu Ngubah Cara Aku Ngoding
Photo by Jason Leung/Unsplash

Dulu, ngoding itu rasanya kayak main tebak-tebakan. Kita tahu fungsinya bakal jalan, tapi kita sering berdoa semoga enggak ada bug aneh muncul di runtime, terutama saat data yang datang ternyata null, undefined, atau bentuknya beda dari yang kita harapkan.

Kalau kamu sudah pakai TypeScript (TS) di proyek Next.js, kamu mungkin merasa selangkah lebih aman. Tapi, jujur saja, banyak developer, termasuk saya dulu, yang menggunakan TS hanya setengah hati. Maksudnya, kita pakai TS tapi masih sering ngandelin any di sana-sini, atau kita biarin konfigurasi TS kita masih "longgar." Ini yang sering disebut sebagai TS comfort zone—aman dari JavaScript murni, tapi masih rentan terhadap kesalahan yang seharusnya bisa dicegah oleh TS.

Setelah beberapa waktu berkutat dengan proyek Next.js yang semakin kompleks dan harus dikerjakan oleh tim yang semakin besar—pengalaman yang sering kami hadapi di Javapixa Creative Studio—saya sadar bahwa "aman" saja tidak cukup. Kita butuh "sangat aman," kita butuh rigor, kita butuh integritas kode yang tinggi. Dan di sinilah keputusan untuk pindah ke Strict Mode TypeScript di Next.js menjadi titik balik terbesar dalam cara saya ngoding.

Ini bukan cuma soal menghindari bug, tapi soal mengubah mindset dari coding to make it work menjadi coding to make it unbreakable.

Kenapa Mode Strict Jadi Kewajiban, Bukan Pilihan

Saat kita membuat aplikasi Next.js, kita berurusan dengan banyak hal: Server Components, Client Components, API Routes, hingga fetching data dari pihak ketiga yang tipenya seringkali tidak terduga. Kalau konfigurasi tsconfig.json kita tidak ketat, semua fitur canggih TS itu jadi sia-sia.

Di Javapixa Creative Studio, standar kami adalah memastikan bahwa setiap software yang kami deliver memiliki scalability dan maintainability kelas enterprise. Dan standar itu dimulai dari mengaktifkan Strict Mode.

Apa sih Strict Mode itu? Secara sederhana, Strict Mode adalah sekumpulan flag di tsconfig.json yang ketika diaktifkan, akan membuat TypeScript jauh lebih cerewet. Dia akan menuntut kita untuk mendefinisikan tipe secara eksplisit, menangani kasus null atau undefined secara wajib, dan memastikan fungsi kita hanya memanggil properti yang benar-benar ada.

json
{
  "compilerOptions": {
    "strict": true, // Ini adalah Master Switch-nya
    // ... setting Next.js lainnya
  }
}

Ketika strict: true diaktifkan, otomatis beberapa flag krusial berikut juga ikut aktif. Dan inilah yang benar-benar mengubah cara saya memandang kode.

---

Tiga Jagoan Utama yang Bikin Hidup Lebih Susah (tapi Lebih Baik)

Mungkin awalnya terasa sulit. Bayangkan, kode yang kemarin lolos compile tiba-tiba penuh coretan merah. Tapi ini adalah rasa sakit yang menyehatkan. Ada tiga flag utama yang membuat saya harus benar-benar mengubah kebiasaan ngoding.

1. strictNullChecks: Goodbye, Runtime Error Tak Terduga

Ini adalah flag yang paling signifikan dan paling sering menimbulkan frustrasi awal.

Di JavaScript biasa, atau TS mode longgar, kita sering lolos saat mengakses properti dari variabel yang mungkin bernilai null atau undefined. Misalnya:

typescript
// Tanpa Strict Null Checks:
let user: { name: string } | null = getUserData();
console.log(user.name); // Ini akan error di runtime kalau user-nya null!

Ketika strictNullChecks aktif, TS langsung teriak: “Hei, user itu bisa null! Kamu tidak boleh langsung mengakses .name tanpa memeriksanya dulu!”

Tips Aplikasif di Next.js:

  • Menangani State di React: Ketika menggunakan useState, pastikan kamu menginisialisasi state dengan nilai yang sesuai.
typescript
    // Dulu (Loose):
    const [data, setData] = useState(); // data bisa undefined
    // Sekarang (Strict): Wajib inisialisasi
    const const [data, setData] = useState(null);
    // ATAU kalau yakin dia akan selalu ada setelah fetching:
    const [data, setData] = useState({ name: '', age: 0 });

Optional Props: Saat mendefinisikan Props di komponen React, gunakan tanda tanya ? untuk properti opsional, dan jangan lupa berikan fallback value* di dalam komponen. Strict Mode memaksa kita untuk sadar betul bahwa data bisa absen.

2. noImplicitAny: Musuh Bebuyutan si ‘Any’ Misterius

Jika kamu baru pindah dari JavaScript ke TypeScript, kamu mungkin suka membiarkan TS "menebak" tipe datanya. Jika TS tidak bisa menebak, dia akan secara implisit memberikan tipe any. noImplicitAny memastikan ini tidak terjadi.

Kenapa ini penting? Karena any adalah lubang keamanan tipe data terbesar. Ketika kamu punya any, kamu kehilangan semua manfaat TypeScript.

Contoh paling umum adalah di parameter fungsi tanpa anotasi tipe:

typescript
// Tanpa noImplicitAny:
function processData(data) { // data secara implisit adalah any
    // ... bebas ngapain aja
}

Tips Aplikasif di Next.js:

Ini sangat terasa di API Routes Next.js (atau Route Handlers). Sebelum Strict Mode, parameter req atau res seringkali ditangani dengan longgar. Tapi dengan Strict Mode, kita dipaksa menggunakan tipe yang sudah disediakan oleh Next.js, seperti NextApiRequest dan NextApiResponse, atau lebih modern lagi menggunakan tipe yang spesifik untuk Route Handlers.

Di Javapixa Creative Studio, kami memastikan setiap fungsi utility yang kami buat memiliki tipe input dan output yang jelas. Ini menghilangkan tebak-tebakan saat developer lain menggunakan fungsi tersebut.

3. strictFunctionTypes: Keamanan Saat Memakai Fungsi Callback

Ini sedikit lebih teknis, tapi dampaknya besar pada keamanan kode, terutama saat kita berurusan dengan fungsi yang bertindak sebagai callback (hal yang sangat umum di React Hooks seperti useEffect atau saat mengirim fungsi sebagai prop).

strictFunctionTypes memastikan bahwa parameter fungsi adalah kontravarian. Sederhananya, jika kamu memiliki fungsi yang mengharapkan input yang sangat spesifik, kamu tidak boleh memberinya fungsi yang menerima input yang lebih umum. Ini melindungi kita dari bug karena salah mengasumsikan tipe input di dalam callback.

---

Migrasi ke Strict Mode: Bukan Lompatan, Tapi Pendakian Bertahap

Mengubah proyek Next.js yang sudah berjalan dari mode longgar ke Strict Mode bisa terasa seperti dihantam tembok. Ratusan error mungkin muncul. Tapi jangan panik. Sebagai tim di Javapixa, kami menemukan cara yang elegan untuk migrasi:

1. Jangan Langsung 'strict: true'

Jika proyekmu besar, jangan aktifkan strict: true sekaligus. Aktifkan flag satu per satu.

  • Mulai dengan noImplicitAny: Ini akan membersihkan semua penggunaan any tersembunyi.

Lanjut ke strictNullChecks: Ini yang paling banyak mengubah kode, memaksa kamu menangani case* null dan undefined.

  • Setelah itu, baru aktifkan sisanya atau nyalakan strict: true.

2. Manfaatkan Utility Types

Untuk mengatasi data yang datang dari luar (misalnya respons API) yang mungkin hanya memiliki beberapa properti, manfaatkan utility types bawaan TS:

  • Partial: Jika kamu hanya perlu sebagian kecil dari tipe data besar.
  • Readonly: Sangat berguna untuk props yang tidak boleh diubah.
  • NonNullable: Untuk memastikan sebuah tipe tidak akan pernah null atau undefined (berguna setelah kamu yakin sudah melakukan pemeriksaan).

3. Hati-hati dengan Non-Null Assertion Operator (!)

Operator ! (misalnya user!.name) memberi tahu TypeScript, "Aku tahu apa yang kulakukan, dan aku yakin ini tidak akan pernah null." Strict Mode memang memaksa kita menggunakan ini, tapi gunakanlah dengan sangat hemat dan hanya setelah kamu benar-benar yakin bahwa variabel tersebut sudah diperiksa sebelumnya atau sudah dijamin keberadaannya (misalnya, di dalam conditional rendering). Penggunaan ! yang ceroboh adalah cara tercepat untuk mengkhianati Strict Mode.

4. Kunci di Komponen Next.js: Props dan Data Fetching

Dalam proyek Next.js, 90% masalah Strict Mode ada di Props dan Data Fetching.

Props: Pastikan interface Props-mu mendefinisikan secara akurat mana yang wajib dan mana yang opsional. Jika opsional, pastikan ada if check atau default value*.

  • Fetching Data: Selalu definisikan tipe respons data sejelas mungkin. Jangan biarkan fetch atau axios mengembalikan any.

typescript
// Contoh di Next.js:
interface Post {
  id: number;
  title: string;
  content: string | null; // Strict Null Checks memaksa kita mendefinisikan null
}

Dengan memaksa kita mendefinisikan bahwa content bisa null, setiap developer yang menggunakan fungsi ini akan tahu bahwa mereka harus menangani kasus null sebelum menampilkan konten. Ini mencegah crash di production.

---

Hasil Akhir: Ngoding Jadi Lebih Lambat, Tapi Jauh Lebih Cepat

Ironisnya, saat pertama kali saya pindah ke Strict Mode, kecepatan ngoding saya terasa melambat. Saya harus menulis lebih banyak tipe, berpikir lebih keras tentang potensi null, dan berjuang melawan kompilator TS.

Namun, perlambatan awal ini menghasilkan percepatan masif di fase debugging dan maintenance.

  1. Zero Runtime Errors (Terkait Tipe): Jika kodenya lolos di TypeScript (apalagi di Strict Mode), probabilitas terjadi kesalahan tipe di runtime hampir nol. Kita tidak perlu lagi menghabiskan waktu berjam-jam mencari tahu kenapa item.price tiba-tiba undefined.
  2. Refactoring Jadi Aman: Inilah manfaat terbesar Strict Mode, terutama untuk tim besar seperti di Javapixa Creative Studio. Ketika kita mengubah nama sebuah properti atau struktur data, TypeScript Strict Mode akan langsung menunjuk semua tempat yang harus diperbarui, bahkan jika itu berada di file yang berbeda. Refactoring dari yang tadinya menakutkan, kini menjadi rutinitas yang aman.
  3. Kualitas Kode Terstandardisasi: Strict Mode memaksa semua anggota tim menulis kode dengan ketelitian yang sama. Tidak ada lagi developer yang 'malas' menulis tipe karena sistem menolak kode yang tidak ketat. Ini adalah fondasi kuat untuk kolaborasi dan code review yang efektif.

Penutup: Jangan Tunda Kualitas

Jika kamu saat ini membangun proyek Next.js, baik itu aplikasi kecil pribadi atau sistem enterprise yang kompleks, beralih ke Strict Mode bukanlah nice-to-have, melainkan must-have.

Di Javapixa Creative Studio, kami percaya bahwa kualitas software sejati tidak hanya diukur dari fitur yang ditawarkan, tapi dari fondasi kode yang solid dan tahan banting. Strict Mode TypeScript adalah salah satu alat terbaik untuk mencapai fondasi tersebut.

Mungkin awalnya sulit, tapi bayangkan ini: kamu menukar waktu berjam-jam mencari bug di production dengan beberapa menit ekstra saat mendefinisikan tipe. Itu adalah pertukaran yang sangat menguntungkan. Jadi, buka tsconfig.json kamu sekarang, ubah "strict": false menjadi true, dan rasakan sendiri perbedaannya. Masa depan ngodingmu yang aman dan terstruktur dimulai sekarang.