Memahami Query Scopes di Laravel untuk Reusable Query Logic

Pendahuluan

Bayangin lagi ngerjain fitur sederhana, tapi tiap kali narik data user yang 'aktif', kamu nulis where('status', 'active') berulang-ulang di berbagai controller. Awalnya kelihatan oke, sampai akhirnya logic status itu berubah, dan kamu harus 'berburu' di seluruh codebase buat ngupdate satu baris kode. Laravel sebenernya udah nyediain penyelamat yang namanya Query Scopes buat ngerapiin kekacauan kayak gini.

Tips & Best Practices

• Di banyak project, biasanya saya mulai dari menamai scope dengan awalan 'scope'. Ini ngebantu banget biar pas dipanggil di controller, kodenya jadi kerasa kayak bahasa manusia biasa, misalnya User::active()->get().
• Pernah kejadian saya salah naruh logic yang kompleks di controller, akhirnya saya pindahin ke Local Scope biar unit testing-nya jauh lebih mudah.
• Saya selalu nyaranin buat pakai Global Scope cuma buat hal-hal yang 'mutlak' harus ada di tiap query, kayak sistem soft delete atau tenant-based filtering, biar nggak bikin pusing di masa depan.

Contoh Kode

Ini cara saya biasa nerapin Local Scope di model User biar query jadi bersih:

// Di dalam User.php
public function scopeActive($query) {
    return $query->where('status', 'active');
}

// Cara pakainya di Controller
$users = User::active()->get();

Variasi Implementasi

Kadang kita butuh scope yang dinamis, contohnya mau filter berdasarkan tanggal. Saya biasanya pakai parameter tambahan: public function scopeRegisteredBetween($query, $from, $to) { ... }. Ini jauh lebih fleksibel daripada bikin banyak scope spesifik. Kalau mau yang otomatis jalan di tiap request, Global Scope memang pilihan utama, tapi hati-hati karena dia 'memaksa' logic-nya di setiap query, kadang malah bikin query jadi lambat kalau modelnya lagi di-join banyak table.

Kesalahan Umum

• Lupa kalau scope harus selalu me-return instance $query, akhirnya malah ngembaliin null dan bikin error yang susah dicari.
• Terlalu banyak pakai Global Scope sampai lupa kalau kita sebenernya nggak butuh filter itu di semua tempat, alhasil performa database malah jadi tumbal.
• Ngasi nama scope yang ambigu, bikin rekan setim bingung maksudnya filter ini buat apa sebenarnya.
• Nulis logic bisnis yang terlalu berat di dalam scope, padahal scope cuma buat ngatur query, bukan buat kalkulasi ribet.
• Lupa nge-chaining scope dengan benar, kadang urutan pemanggilan scope bisa ngaruh ke hasil akhir query kalau ada operator orWhere yang nyempil di tengah.

Ringkasan

Memahami Query Scopes itu bukan cuma soal rapi-rapiin kode, tapi soal investasi biar besok-besok pas requirement berubah, kamu nggak perlu lembur buat benerin logic yang kesebar dimana-mana. Intinya, kalau kamu merasa nulis query yang sama lebih dari dua kali, itu tanda waktunya pake scope.