Table Filter Filament yang Benar-Benar Dipakai

Setiap kali saya bikin resource baru di Filament, godaan pertama biasanya sama: tambahkan filter untuk hampir semua kolom yang ada. Status ada filternya, tanggal ada filternya, relasi ada filternya, bahkan kolom boolean kecil pun dikasih toggle filter sendiri. Hasilnya panel filter yang penuh, tapi anehnya tim operasional tetap cuma scroll manual atau pakai pencarian bebas. Filter jadi dekorasi, bukan alat kerja.

Masalahnya bukan di Filament-nya. Filament menyediakan builder filter yang sangat fleksibel — SelectFilter, TernaryFilter, Filter custom dengan form sendiri, sampai filter berbasis relasi. Masalahnya ada di sisi kita sebagai developer: kita sering merancang filter berdasarkan "kolom apa yang ada di tabel", bukan "pertanyaan apa yang sering ditanyakan tim saat kerja". Dua pendekatan ini menghasilkan panel filter yang sangat berbeda.

Mulai dari pertanyaan operasional, bukan dari skema database

Cara paling efektif yang saya pakai adalah duduk sebentar dengan tim yang benar-benar pakai tabel itu setiap hari, lalu tanya: "kalau kamu buka layar ini, kamu biasanya cari apa dulu?" Di sistem operasional — entah itu antrian, transaksi, atau data pasien di lingkungan klinis — jawabannya biasanya berulang: status yang masih pending, rentang tanggal hari ini/minggu ini, atau milik cabang/unit tertentu. Itulah tiga kandidat filter paling kuat, dan sering kali cukup tiga itu saja.

Sebagai ilustrasi, kalau ada resource dengan 15 kolom, bukan berarti harus ada 15 filter. Saya biasanya mulai dari maksimal tiga sampai lima filter di iterasi pertama, lalu tambah kalau memang ada kebutuhan nyata yang muncul belakangan. Menambah filter itu murah — tinggal tambah baris di method filters(). Tapi mengurangi filter yang sudah dipakai orang jauh lebih mahal secara sosial, karena selalu ada satu-dua orang yang sudah terbiasa pakai filter itu meski jarang.

Pilih tipe filter sesuai pola datanya

Kolom status atau enum cocok pakai SelectFilter dengan opsi terbatas dan jelas, bukan dropdown yang isinya ratusan nilai unik dari database. Untuk kolom boolean seperti "aktif/tidak aktif", TernaryFilter lebih pas karena punya tiga state — ya, tidak, dan semua — daripada checkbox biasa yang ambigu antara "false" dan "tidak difilter". Untuk rentang tanggal, saya hampir selalu pakai Filter custom dengan dua input date agar bisa query whereBetween, dan sebisa mungkin beri default rentang yang masuk akal, misalnya bulan berjalan, supaya user tidak harus isi manual setiap buka halaman.

SelectFilter::make('status')
    ->options([
        'pending' => 'Menunggu',
        'processed' => 'Diproses',
        'done' => 'Selesai',
    ]),

Contoh sesederhana itu jauh lebih berguna daripada filter generik untuk kolom yang jarang jadi kriteria pencarian, seperti nama pembuat data atau timestamp update terakhir. Kolom-kolom itu lebih cocok ditampilkan sebagai informasi di tabel, bukan dijadikan filter.

Filter yang tidak dipakai adalah utang, bukan fitur

Satu kebiasaan yang saya coba jaga: sesekali cek filter mana yang benar-benar dipakai tim, misalnya lewat obrolan singkat atau observasi langsung saat mereka kerja. Filter yang tidak pernah disentuh bukan cuma tidak berguna, tapi juga menambah beban kognitif — user harus mikir sejenak "ini perlu saya isi atau tidak" tiap kali buka halaman. Lebih baik dihapus atau digabung, lalu ditambah lagi kalau memang muncul kebutuhannya.

Takeaway

Table filter di Filament sebaiknya dirancang dari kebutuhan kerja harian tim, bukan dari daftar kolom yang tersedia. Mulai kecil dengan filter yang paling sering jadi pertanyaan operasional, pilih tipe filter yang cocok dengan pola datanya, dan jangan segan mengurangi filter yang ternyata tidak dipakai. Panel filter yang ramping dan relevan jauh lebih membantu daripada panel yang lengkap tapi jarang disentuh.