2.3 KiB
paths
| paths | |
|---|---|
|
Pages
Non-Resource Filament pages need an explicit table-rendering view + deferLoading-aware tests
A Filament\Pages\Page implements HasTable (not a Resource) does NOT render its table automatically — it must set protected string $view = '<module>::filament.pages.<slug>'; pointing at a Blade file containing <x-filament-panels::page>{{ $this->table }}</x-filament-panels::page> (see ManageFaqs/ViewEvChatHistory/BookingsRevenueReport). Omitting this silently renders an empty page — no error, just a blank fi-page-content.
Filament v4 tables default to deferred loading. In Pest/Livewire tests, call ->loadTable() before any assertSee()/assertCanSeeTableRecords() on a freshly-mounted component, or the table body won't be in the rendered HTML yet.
For custom-data (->records()-backed, non-Eloquent) tables: use ->callTableAction($name, $record, data: [...]) / ->mountTableAction(...) (not the generic ->callAction(), which targets page-level actions and misses table header/record actions), and use ->assertMountedActionModalSee(...) to check ->modalContent() output — modal content is lazily rendered and won't appear in a plain ->html()/->assertSee() snapshot even after mounting the action. See [[project_internachi_modular]]-style module layout in app-modules/ai-agent.
Custom-data table bulk actions: fetchSelectedRecords(false) still hydrates full rows
On a Table::records()-backed (non-Eloquent) page, BulkAction::make(...)->fetchSelectedRecords(false) does NOT skip hydration the way it does for an Eloquent table — the Collection $records passed to ->action() still contains full row arrays (keyed by the record key), not bare ids. Use $records->keys()->all() to get just the selected ids; $records->all()/$records->values() gives you full row data instead. See ManageSuggestions::deleteSelectedBulkAction() / ManageSuggestionMisses::promoteBulkAction().
Also: BnfexpressAdminClient's non-2xx handling (errorMessage()) must handle detail being a list of {msg, ...} objects, not just a string — FastAPI's own request-validation failures (422s) return detail in that shape, and casting it straight to (string) silently produces the literal "Array".