Masalah umum pada form bukan hanya validasi yang terlewat, tetapi ketidaksinkronan antara tipe TypeScript, aturan input, dan bentuk payload akhir. Zod cukup efektif untuk menyatukan tiga hal itu.
Begitu schema dipakai sebagai sumber kebenaran, refactor jadi lebih aman. Field baru atau aturan baru tidak perlu dikejar manual di banyak file yang tersebar.
Mulai dari bentuk data akhir
Langkah awal yang paling berguna adalah menulis schema dari sudut pandang payload akhir, bukan dari field input satu per satu. Dengan begitu, kita tahu data seperti apa yang sebenarnya dibutuhkan sistem.
Setelah payload akhir jelas, barulah schema dipecah menjadi aturan per field dan optional transform yang memang diperlukan.
Pikirkan output sebelum input
- Apa payload akhir yang dibutuhkan server?
- Field mana yang opsional?
- Transform apa yang benar-benar perlu terjadi sebelum submit?
Gunakan fitur schema secukupnya
Zod sangat kuat, tetapi tetap perlu disiplin. Saya menghindari transform yang terlalu banyak dalam satu schema karena sulit dibaca dan menyulitkan debugging ketika value berubah di tengah jalan.
Kalau logika transform sudah seperti business rule, lebih baik dipindahkan ke lapisan yang lebih eksplisit.
Jaga satu sumber kebenaran untuk form
Keuntungan terbesar schema yang rapi adalah konsistensi. Error message, typing, dan submit payload mengikuti sumber yang sama, sehingga tim tidak perlu terus menyamakan asumsi antar layer.
Untuk form yang sering berubah, pola ini terasa sangat hemat waktu dalam jangka panjang.
const profileSchema = z.object({
name: z.string().min(2),
email: z.string().email(),
role: z.enum(['admin', 'editor', 'viewer']),
})