Why Go Beyond Built-In Filament Components
Filament v3 ships with a rich component library, but production panels inevitably need things the core doesn't provide: a colour-swatch picker tied to your design system, a table column that renders a sparkline, or a persistent banner injected above every resource table without touching vendor views. The three primitives that cover these cases are custom field plugins, custom table columns, and render hooks.
Building a Reusable Custom Field Plugin
A Filament field plugin is a class that extends Filament\Forms\Components\Field and ships its own Blade view. The cleanest approach is to extract it into a dedicated package or a app/Filament/Forms/Components namespace.
// app/Filament/Forms/Components/ColourSwatchInput.php
namespace App\Filament\Forms\Components;
use Filament\Forms\Components\Field;
class ColourSwatchInput extends Field
{
protected string $view = 'filament.forms.components.colour-swatch-input';
protected array $swatches = [];
public function swatches(array $swatches): static
{
$this->swatches = $swatches;
return $this;
}
public function getSwatches(): array
{
return $this->swatches;
}
}
The Blade view receives $getSwatches() via Filament's magic view data injection:
{{-- resources/views/filament/forms/components/colour-swatch-input.blade.php --}}
<x-dynamic-component :component="$getFieldWrapperView()" :field="$field">
<div class="flex gap-2 flex-wrap">
@foreach ($getSwatches() as $hex)
<button
type="button"
wire:click="$set('{{ $getStatePath() }}', '{{ $hex }}')"
class="w-8 h-8 rounded-full border-2 {{ $getState() === $hex ? 'border-primary-500' : 'border-transparent' }}"
style="background-color: {{ $hex }}"
></button>
@endforeach
<input type="hidden" {{ $applyStateBindingModifiers('wire:model') }}="{{ $getStatePath() }}">
</div>
</x-dynamic-component>
Usage in a resource form:
ColourSwatchInput::make('brand_colour')
->swatches(['#FF5733', '#33FF57', '#3357FF'])
->required(),
Typed Custom Table Columns
Custom columns extend Filament\Tables\Columns\Column and follow the same view-injection pattern. The key discipline is keeping state derivation inside the column class, not the Blade template.
// app/Filament/Tables/Columns/StatusBadgeColumn.php
namespace App\Filament\Tables\Columns;
use Filament\Tables\Columns\Column;
class StatusBadgeColumn extends Column
{
protected string $view = 'filament.tables.columns.status-badge';
protected array $colorMap = [];
public function colorMap(array $map): static
{
$this->colorMap = $map;
return $this;
}
public function getColor(): string
{
return $this->colorMap[$this->getState()] ?? 'gray';
}
}
{{-- resources/views/filament/tables/columns/status-badge.blade.php --}}
<x-filament::badge :color="$getColor()">
{{ str($getState())->headline() }}
</x-filament::badge>
Registering it in a resource table:
StatusBadgeColumn::make('status')
->colorMap([
'active' => 'success',
'pending' => 'warning',
'archived' => 'danger',
])
->sortable(),
Render Hooks: Injecting UI Without Patching Views
Render hooks let you insert Blade content at named slots across the Filament shell — no view overrides, no @extends hacks.
Register hooks inside a service provider or panel provider:
use Filament\Support\Facades\FilamentView;
use Filament\View\PanelsRenderHook;
FilamentView::registerRenderHook(
PanelsRenderHook::RESOURCE_PAGES_LIST_RECORDS_TABLE_BEFORE,
fn (): string => view('filament.banners.maintenance-notice')->render(),
);
For hooks that need Livewire reactivity, return a View instance and let Filament handle rendering:
use Illuminate\Contracts\View\View;
FilamentView::registerRenderHook(
PanelsRenderHook::GLOBAL_SEARCH_BEFORE,
fn (): View => view('filament.partials.environment-ribbon', [
'env' => app()->environment(),
]),
);
Available hook constants live in Filament\View\PanelsRenderHook. Scope a hook to a specific page class to avoid polluting every panel page:
FilamentView::registerRenderHook(
PanelsRenderHook::PAGE_HEADER_ACTIONS_BEFORE,
fn (): string => '<div class="text-xs text-gray-400">Last synced: ' . cache('last_sync') . '</div>',
scopes: App\Filament\Resources\OrderResource\Pages\ListOrders::class,
);
Key Takeaways
- Custom fields extend
Field, declare a$view, and expose typed getter methods — keep logic out of Blade. - Custom columns follow the same pattern; derive computed state (colours, labels) inside the column class.
- Render hooks are the correct extension point for injecting persistent UI; use
scopesto limit blast radius. - Always bind
wire:modelvia$applyStateBindingModifiers()in field views to respect deferred/lazy modifiers. - Ship custom components in a dedicated namespace or package so they're testable in isolation with Pest.