Cara Membuat Custom Validation Rule di Laravel 12 yang Efektif

Pendahuluan

Bayangin lagi ngerjain fitur sederhana, tapi tiba-tiba requirement client nambah ribet soal format input yang harus divalidasi dengan logika bisnis yang spesifik. Biasanya, kita langsung lempar logika itu ke dalam Controller, tapi lama-lama kodenya jadi berantakan. Di Laravel 12, kita punya cara yang jauh lebih rapi lewat Custom Validation Rule yang bisa dipakai ulang di mana saja tanpa bikin controller bengkak.

Tips & Best Practices

• Di banyak project, biasanya saya mulai dengan membuat Rule di folder terpisah biar struktur proyek tetap terjaga dan mudah dicari saat debugging.
• Kalau validasi butuh akses ke database, saya sering pakai interface ValidationRule yang menyediakan metode validate untuk menjaga performa tetap optimal.
• Untuk tim yang besar, saya selalu menyarankan menulis test case terpisah untuk rule tersebut agar perubahan di masa depan nggak bikin fitur lain 'jebol' tanpa disadari.

Contoh Kode

Misalnya, kita perlu validasi username yang nggak boleh mengandung kata kasar. Cukup jalankan php artisan make:rule NoBadWords, lalu isikan logikanya:

public function validate(string $attribute, mixed $value, Closure $fail): void
{
    $badWords = ['admin', 'root', 'super'];
    if (in_array(strtolower($value), $badWords)) {
        $fail('Username ini tidak diperbolehkan karena alasan keamanan.');
    }
}

Variasi Implementasi

Selain membuat class Rule, kita bisa pakai Closure-based validation kalau fiturnya simpel banget dan cuma dipakai di satu form. Tapi, kalau logikanya kompleks atau dipakai di banyak tempat (seperti validasi SKU produk atau format NIK), pakai class terpisah adalah pilihan wajib supaya kode kita tetap DRY (Don't Repeat Yourself).

Kesalahan Umum

• Lupa melakukan sanitasi input sebelum masuk ke logika validasi, yang bisa berujung pada celah keamanan.
• Menaruh terlalu banyak query database di dalam metode validate, sehingga proses request jadi lambat.
• Memberikan pesan error yang terlalu teknis bagi user biasa, padahal pesannya harus informatif.
• Menggunakan Rule yang sama untuk input yang berbeda konteks, padahal mestinya dipisah agar lebih fleksibel.
• Tidak menangani kasus data kosong atau null dengan benar, yang sering bikin error nggak terduga saat form di-submit.

Ringkasan

Pada akhirnya, custom rule bukan cuma soal validasi input, tapi tentang menjaga sanity kita sebagai developer supaya codebase tetap bersih. Jangan takut untuk membungkus logika bisnis yang repetitif ke dalam rule mandiri, karena itulah investasi terbaik untuk proyek jangka panjang.