Ketika TypeScript menolak sebuah nilai, menambahkan as sering menjadi jalan tercepat untuk membuat garis merah hilang. Namun, assertion bukan konversi data dan bukan pemeriksaan runtime. Ia menyampaikan keyakinan pengembang kepada pemeriksa tipe. Jika keyakinan itu salah, program tetap dapat menerima nilai yang tidak sesuai dan gagal ketika properti atau operasi tertentu akhirnya digunakan pada jalur yang sebelumnya tidak pernah diuji.
Mulailah dengan membaca hubungan yang sedang dipersoalkan. Fungsi mungkin menerima string atau number, sementara operasi berikutnya hanya berlaku untuk number. Atau hasil jaringan dianggap selalu mempunyai objek pengguna, padahal respons dapat kosong. Pesan tipe sering menunjuk asumsi yang belum dinyatakan. Tujuan perbaikan bukan membungkam pemeriksa, melainkan menjelaskan mengapa operasi aman pada keadaan yang benar-benar mungkin terjadi saat kode berjalan.
Bedakan pengetahuan tipe dan keadaan runtime
TypeScript menganalisis program berdasarkan deklarasi serta alur yang dapat dikenali. Ia tidak otomatis memastikan bahwa server luar mengirim data sesuai interface yang kamu tulis. Jika sumber data berada di luar kendali program, periksa batas tersebut secara eksplisit. Deklarasi tipe membantu pekerjaan pengembangan, sedangkan validasi runtime memeriksa nilai nyata. Keduanya berkaitan, tetapi tidak saling menggantikan ketika aplikasi menerima masukan dari jaringan atau pengguna.
Gunakan unknown ketika nilai belum diketahui bentuknya dan perlu diperiksa sebelum dipakai. Berbeda dengan membiarkan operasi bebas melalui any, unknown mendorong kode memperjelas pemeriksaan. Namun, memilih unknown saja belum menyelesaikan persoalan. Kamu tetap perlu menentukan bentuk yang diterima, bagaimana kondisi lain ditangani, dan pesan apa yang sesuai jika data tidak memenuhi kebutuhan yang diperlukan oleh fitur pada aplikasi tersebut.
Pemeriksaan sederhana harus sesuai operasi
Untuk nilai primitif, typeof dapat membantu mempersempit kemungkinan tipe. Jika operasi membutuhkan teks, periksa bahwa nilainya string sebelum memanggil metode string. Jangan menggunakan pemeriksaan truthy sebagai satu-satunya syarat ketika nilai kosong, nol, atau false bisa sah. Pemeriksaan yang terlalu umum dapat membuang masukan valid dan menimbulkan perilaku yang tidak terlihat ketika pengujian hanya menggunakan contoh dengan nilai yang dianggap normal.
Gunakan pembeda yang mewakili keadaan
Objek hasil operasi sering lebih jelas jika mempunyai penanda seperti status atau kind. Cabang sukses membawa data, sedangkan cabang gagal membawa informasi kesalahan. Discriminated union membantu pemeriksa tipe mengikuti hubungan itu ketika setiap anggota mempunyai nilai pembeda yang jelas. Hindari satu objek dengan banyak properti opsional yang membuat kombinasi tidak masuk akal tetap terlihat mungkin pada seluruh bagian program.
Misalnya, data yang sedang dimuat tidak seharusnya sekaligus dianggap berhasil dengan hasil lengkap jika desain memang membedakan keduanya. Representasi keadaan yang tepat mempermudah komponen menentukan tampilan. Namun, model tipe tetap harus mengikuti kebutuhan sebenarnya. Jangan menambah variasi status hanya agar terlihat rumit; pilih keadaan yang berbeda perilaku dan mempunyai arti bagi pengguna atau proses yang dijalankan oleh aplikasi tersebut.
Periksa objek dari luar secara bertahap
Sebelum membaca properti bertingkat, periksa bahwa nilai memang objek yang diharapkan dan bukan null. Untuk daftar, periksa struktur array dan elemen sesuai kebutuhan. Keberadaan sebuah properti tidak otomatis membuktikan semua isinya valid. Tulis pemeriksaan berdasarkan data yang benar-benar dipakai, sambil mempertimbangkan field wajib, rentang nilai, dan kemungkinan format berubah tanpa menganggap setiap rincian respons harus diperiksa dengan aturan yang sama.
Type predicate dapat merangkum pemeriksaan agar dipakai ulang, tetapi implementasinya harus benar. Fungsi yang mengaku membuktikan sebuah tipe tanpa memeriksa nilainya hanya memindahkan assertion ke tempat lain. Tambahkan pengujian untuk masukan salah, bukan hanya contoh yang memenuhi tipe. Jika aturan kompleks, pertimbangkan validator yang telah digunakan dalam proyek daripada menyusun banyak pemeriksaan manual yang sulit ditinjau ketika spesifikasi data berubah.
Jangan memaksa tipe untuk menutupi kontrak salah
Jika fungsi selalu memerlukan data lengkap, perbaiki pemanggil agar tidak menjalankannya sebelum data tersedia. Jika data memang boleh kosong, ubah kontrak serta penanganannya. Assertion berulang dapat menjadi petunjuk bahwa batas fungsi tidak jelas. Tinjau desainnya sebelum menambah pengecualian di banyak lokasi. Perbaikan pada satu batas sering lebih mudah dipelihara daripada daftar asumsi yang tersebar dan harus diperbarui sendiri pada setiap komponen.
Uji jalur yang dianggap mustahil
Masukan kosong, respons lama, dan data yang berubah adalah contoh yang sering memperlihatkan celah asumsi. Buat kasus kecil yang dapat dijalankan tanpa seluruh aplikasi. Periksa apakah hasilnya ditolak dengan jelas atau justru menyebabkan error jauh dari sumber data. Lokasi kegagalan yang dekat dengan batas masukan membantu diagnosis, karena pengembang tidak perlu menelusuri banyak fungsi sebelum menemukan nilai pertama yang sebenarnya bermasalah.
Gunakan assertion ketika ada alasan yang dapat dijelaskan dan bukti yang memadai, bukan sebagai kebiasaan menghadapi setiap pesan tipe. Simpan alasan yang tidak jelas dalam dokumentasi atau pengujian. Kode yang dapat menunjukkan bagaimana keyakinannya diperoleh lebih mudah diperiksa daripada kode yang hanya menyatakan percaya. Pemeriksa tipe membantu menemukan pertanyaan, sedangkan pengembang tetap bertanggung jawab menjawabnya melalui rancangan dan perilaku program yang benar.
Bedakan perbaikan lokal dan akar masalah
Jika error muncul di banyak komponen, periksa tempat data pertama kali diterima. Konversi atau validasi yang konsisten pada batas itu dapat mengurangi pemeriksaan berulang. Namun, jangan menyembunyikan keadaan gagal dengan nilai bawaan yang menyesatkan. Pengguna perlu tahu ketika data memang tidak tersedia, bukan melihat angka nol yang sebenarnya menggantikan respons tidak valid.
