Relation Manager Filament untuk Data Bertingkat

Hampir semua sistem yang pernah saya tangani di lingkungan klinik atau rumah sakit punya pola data yang sama: satu entitas induk dengan banyak data anak yang terus bertambah. Pasien punya riwayat kunjungan, kunjungan punya tindakan, tindakan punya biaya. Kalau setiap kali admin harus pindah halaman untuk melihat atau mengedit data anak, alur kerjanya jadi lambat dan gampang membuat frustrasi. Di sinilah Relation Manager Filament jadi salah satu fitur yang paling sering saya pakai—bukan karena canggih, tapi karena langsung menjawab kebutuhan nyata: menampilkan dan mengelola data bertingkat tanpa keluar dari konteks halaman induk.

Kenapa Data Bertingkat Butuh Pendekatan Khusus

Kalau relasi antar tabel hanya ditampilkan sebagai dropdown atau tabel pivot biasa, admin kehilangan konteks. Misalnya saat melihat detail pasien, yang paling relevan bukan sekadar nama dan alamatnya, tapi riwayat kunjungannya—kapan datang, diagnosis apa, tindakan apa. Menaruh data ini di halaman terpisah memaksa pengguna berpindah-pindah dan mengingat ID secara manual. Relation Manager menyelesaikan ini dengan menyematkan tabel relasi langsung sebagai tab di halaman resource induk, lengkap dengan aksi create, edit, dan delete tanpa perlu resource terpisah untuk data anak.

Konsepnya Sederhana: Relasi Eloquent, Bukan Sihir

Relation Manager di Filament sebenarnya cuma pembungkus dari relasi Eloquent yang sudah biasa kita tulis, seperti hasMany atau belongsToMany. Yang membuatnya berguna adalah Filament otomatis menyediakan UI table, form, dan aksi CRUD berdasarkan relasi itu, tanpa saya harus membangun controller dan view terpisah. Ini cocok untuk kasus di mana data anak tidak cukup penting untuk punya resource sendiri di sidebar, tapi tetap perlu dikelola dengan mudah.

Membuat Relation Manager untuk Riwayat Kunjungan

Sebagai ilustrasi, anggap kita punya model Patient dengan relasi hasMany ke model Visit. Langkah dasarnya kira-kira begini:

php artisan make:filament-relation-manager PatientResource visits visit_date

Argumen terakhir di sini adalah kolom yang dipakai Filament sebagai judul/label record anak (misalnya tanggal kunjungan), bukan foreign key-nya—foreign key sudah otomatis mengikuti relasi Eloquent yang didefinisikan. Perintah ini menghasilkan class VisitsRelationManager yang saya lengkapi dengan definisi form dan table, misalnya:

public function form(Form $form): Form
{
    return $form->schema([
        Forms\Components\DatePicker::make('visit_date')->required(),
        Forms\Components\Select::make('diagnosis')->options([...]),
        Forms\Components\Textarea::make('notes'),
    ]);
}

public function table(Table $table): Table
{
    return $table
        ->columns([
            Tables\Columns\TextColumn::make('visit_date')->date(),
            Tables\Columns\TextColumn::make('diagnosis'),
        ])
        ->headerActions([Tables\Actions\CreateAction::make()])
        ->actions([Tables\Actions\EditAction::make(), Tables\Actions\DeleteAction::make()]);
}

Setelah class ini didaftarkan di method getRelations() pada resource induk, tab riwayat kunjungan langsung muncul di halaman edit pasien, lengkap dengan tombol tambah, ubah, dan hapus.

Hal-hal yang Perlu Diperhatikan

• Jangan bersarang terlalu dalam. Relation Manager di dalam Relation Manager biasanya membuat UI berat dan membingungkan. Kalau data anak punya anak lagi, pertimbangkan membuat halaman detail terpisah untuk level kedua.
• Perhatikan query performance. Karena tabel relasi dimuat di halaman yang sama, pastikan relasi punya index yang tepat dan hindari eager loading yang tidak perlu, apalagi kalau jumlah data anak bisa besar.
• Batasi aksi sesuai peran. Untuk data sensitif seperti riwayat medis, saya biasa membatasi aksi edit atau delete lewat policy, bukan hanya menyembunyikan tombolnya di UI.
• Gunakan tab kalau relasinya lebih dari satu. Filament mendukung banyak Relation Manager sekaligus per resource, ditampilkan sebagai tab—ini membantu kalau induk punya beberapa jenis data anak, misalnya kunjungan dan pembayaran.

Intinya, Relation Manager adalah salah satu cara paling efisien di Filament untuk merepresentasikan struktur data bertingkat tanpa membangun resource dan navigasi terpisah untuk setiap level. Untuk kebanyakan kasus data induk-anak di aplikasi bisnis maupun klinis, pola ini cukup untuk memberikan pengalaman admin yang cepat dan kontekstual—selama kita tetap disiplin soal kedalaman relasi dan performa query di baliknya.