Cara Membuat Custom Validation Rule di Laravel 12 yang Efektif

Pendahuluan

Bayangin lagi ngerjain fitur sederhana, tapi validasi bawaan Laravel kayak 'required' atau 'email' ternyata nggak cukup buat nge-handle logic bisnis yang unik di aplikasi kamu. Biasanya, kita bakal tergoda buat naruh logic validasi langsung di dalam Controller, yang akhirnya malah bikin file controller jadi gemuk dan susah dibaca. Padahal, Laravel sudah nyediain cara elegan buat memisahkan logic ini biar kode kamu tetep rapi dan bisa dipakai ulang.

Tips & Best Practices

Di banyak project, biasanya saya mulai dari menempatkan rule di folder app/Rules agar rapi sejak awal daripada bikin anonymous rule yang bikin controller berantakan. Saat tim makin besar, saya selalu menyarankan untuk mendokumentasikan setiap class rule lewat komentar yang jelas supaya rekan setim nggak bingung pas maintenance. Terakhir, saya terbiasa buat memastikan rule tersebut tetap stateless—nggak bergantung pada data di luar input yang divalidasi—supaya testability-nya terjaga dengan baik.

Contoh Kode

Katakanlah kamu punya kasus validasi username yang harus mengandung karakter khusus. Cukup generate via artisan php artisan make:rule UppercaseUsername, lalu implementasikan logic-nya seperti ini:

public function validate(string $attribute, mixed $value, Closure $fail): void { if (!str_contains($value, '#')) { $fail('Username harus mengandung simbol #'); } }

Setelah itu, tinggal panggil di FormRequest atau Controller: 'username' => ['required', new UppercaseUsername].

Variasi Implementasi

Kalau logic validasinya simpel banget, pake Rule::macro atau Closure di controller itu oke-oke aja biar cepet. Tapi, pas validasi itu butuh akses ke database (misal: cek kuota user), class-based rule jauh lebih unggul karena bisa di-inject dependency-nya via constructor. Jangan paksain pake class kalau cuma buat ngecek format string sederhana.

Kesalahan Umum

1. Naruh query database yang berat di dalam method validate tanpa caching, yang bikin aplikasi lemot pas validasi jalan. 2. Lupa nambahin pesan error kustom, sehingga user dapet pesan default yang nggak informatif. 3. Bikin rule yang terlalu spesifik buat satu form, padahal bisa dibuat lebih general. 4. Nggak ngetest rule dengan input edge-case kayak null atau tipe data yang aneh. 5. Terlalu banyak bikin class kecil yang sebenernya bisa disatuin jadi satu rule yang parametrik.

Ringkasan

Membuat custom validation rule itu investasi jangka panjang buat kesehatan codebase. Jangan biarin logika bisnis yang rumit berserakan di controller, karena pas nanti ada perubahan requirement, kamu bakal berterima kasih sama diri sendiri yang udah rapihin logic validasi di tempat yang seharusnya.