Filament Saved Views Laravel Package

Getting Started

Install the package with Composer and complete the standard Filament package setup:

composer require happenv-com/filament-saved-views
php artisan vendor:publish --tag="filament-saved-views-migrations"
php artisan migrate

Publish the config if the package exposes one, then review config/filament-saved-views.php for table names, user/tenant scoping, and sharing defaults.

Where to look first:

• The package README for the exact trait/interface/plugin registration names.
• The published migration to understand how views are scoped to users/teams.
• The Filament list page or resource where you will enable saved views.

First use case: add saved views to a Filament table so users can persist filters, sort order, search, and column visibility as named views. After upgrading to v1.8.0, use hasSavableTableState() to avoid offering “Save view” when the table is still in its default state.

Typical first integration:

use Happenv\FilamentSavedViews\Concerns\HasSavedViews; // verify exact namespace in package docs

class ListPosts extends ListRecords
{
    use HasSavedViews;
}

Then expose the package’s saved-view action/header component on that table. Start with one high-traffic resource and confirm that saving, loading, and deleting a view works before rolling it out.

Implementation Patterns

Attach saved views at the Filament list-page level, not globally. This keeps the trait close to the table whose state is being persisted and avoids surprising behavior on unrelated pages.

Use hasSavableTableState() in custom UI when you build your own save action:

Action::make('saveView')
    ->visible(fn (): bool => $this->hasSavableTableState())
    ->action(fn () => $this->saveCurrentTableView());

Or disable rather than hide it if you want users to understand why saving is unavailable:

->disabled(fn (): bool => ! $this->hasSavableTableState())

Common day-to-day patterns:

• Personal views: let users save private presets such as “My open tickets” or “Renewals this month.”
• Shared/team views: expose shared views only when the package’s sharing/policy configuration is enabled.
• Default views: designate a saved view as the default for a resource, but keep an easy way to return to the unmodified table.
• Tenant/panel scoping: verify saved views are scoped to the current tenant or panel if your app uses Filament tenancy or multiple panels.
• Custom actions: call hasSavableTableState() inside Livewire action closures or Blade after the table has initialized, not in mount().

If the package provides its own save action, check whether v1.8.0 already uses hasSavableTableState() internally. If it does not, wrap or replace the action visibility with the method.

For resources with heavy custom table state, override hasSavableTableState() on the page and add your own checks:

public function hasSavableTableState(): bool
{
    return parent::hasSavableTableState()
        || $this->customTableMode !== null;
}

This keeps the save UI aligned with the state your application actually persists.

Gotchas and Tips

• hasSavableTableState() is a UI helper, not an authorization check. Still enforce who can create, update, or share saved views through policies or package config.
• Test the method against each state type you rely on: filters, search, sort, column visibility, per-page settings, and any custom table state. If a state type is not detected, override the method or extend the package behavior.
• Do not call the method too early in the Livewire lifecycle. Use it in action visibility/disabled closures or Blade rendered after the table is configured.
• Saved views can become stale when filters reference deleted options or renamed columns. Provide a way for users to delete or reset broken views, and consider validating loaded state.
• In multi-tenant or multi-panel apps, confirm the saved views table includes the right scoping columns and that queries are constrained by tenant/panel. Otherwise users may see views from the wrong context.
• After upgrading to v1.8.0, clear cached views/config if the save action still appears on an unchanged table. The release is additive, but stale caches can mask the new behavior.
• When debugging, inspect the live table state (tableFilters, tableSort, tableSearch, column toggles) and compare it with what the package persists. A quick dump($this->hasSavableTableState()) inside an action closure usually reveals whether the issue is state detection or UI wiring.
• Use the method as an extension point: if your app has additional persisted table settings, override it so the “Save view” affordance appears only when those settings differ from defaults.
• Keep the package’s config and migrations under version control, and review them on upgrade. Filament packages often add config keys or schema changes in minor releases.