Inline Child Records with FilamentPHP RelationManager: Practical Engineering Decision

Inline Child Records with FilamentPHP RelationManager

When a parent resource such as a post needs to manage a tightly coupled child model like comments, the usual approach is to create a separate top‑level resource. That forces admins to leave the parent page, duplicate breadcrumb navigation, and repeat authorization wiring for each child type.

Why embed the child inline?

FilamentPHP’s RelationManager lets you place a child model’s form and table directly on the parent’s edit or view page. The child records are automatically scoped to the current parent, so administrators stay in context and avoid unnecessary navigation.

How it works

1. Define a hasMany relationship between the parent and child models.
2. Create a RelationManager class for the child, specifying a form schema and a paginated table configuration.
3. Register the RelationManager on the parent resource’s pages method.

Worked example

class Post extends \Filament\Tables\Table
{
    use \Filament\Tables\Concerns\HasTable;

    protected $model = \App\Models\Post::class;

    public function mount()
    {
        // No extra code needed; the RelationManager is attached below
    }

    public function getRelationManagers(): array
    {
        return [
            'comments' => \Filament\Relations\RelationManager::make('comments')
                ->label('Comments')
                ->relationship('comments')
                ->form(\App\Form\PostComment::class)
                ->table([
                    'columns' => [
                        'body' => ['type' => 'text'],
                        'author' => ['type' => 'text'],
                    ],
                    'searchable' => ['body'],
                    'filters' => ['author'],
                    'perPage' => 10,
                ]),
        ];
    }
}

The Post model has a hasMany relation named comments. The RelationManager is automatically filtered to the current post_id because Filament scopes the query to the parent record.

Trade‑offs and limitations

• Performance: Rendering a large child table on the parent edit page can increase initial load time. Use pagination and avoid eager‑loading heavy relations in the parent query.
• Cognitive load: Too many fields on one screen may overwhelm users. Keep the parent form lean and let the RelationManager handle the child details.
• Policy enforcement: RelationManager does not replace Laravel policies; child‑model policies must still be defined for create, update, and delete actions.

Verification steps

1. Scaffold a parent resource (e.g., php artisan filament:resource Post) and inspect the generated class to see which method attaches relation managers in your Filament version.
2. Create a simple PostComment model with belongsTo and hasMany sides, then open a post’s edit page. Confirm the comments table appears and only shows comments belonging to that post.
3. Check the official upgrade guide or changelog for your Filament version to ensure the RelationManager API has not changed.

Conclusion

If the child record rarely makes sense outside its parent and administrators manage it inline, a RelationManager is the pragmatic choice. Otherwise, a standalone resource offers clearer separation and easier cross‑parent queries. Start with separate resources, extract RelationManagers once the workflow stabilizes, and always paginate the child table to keep performance acceptable.