Колонки, які можна ховати:
TextColumn::make('email')
->toggleable(),
TextColumn::make('id')
->toggleable(isToggledHiddenByDefault: true), // прихована, але доступна
У таблиці з'являється менеджер колонок, де користувач вмикає й вимикає їх. reorderableColumns() дозволяє ще й міняти порядок.
Стан колонок зберігається в сесії за замовчуванням - після переходу на іншу сторінку й назад користувач бачить свій набір. Вимкнути: ->persistColumnsInSession(false).
Що ще можна зберігати в сесії (за замовчуванням вимкнено):
$table
->persistFiltersInSession()
->persistSortInSession()
->persistSearchInSession()
->persistColumnSearchesInSession();
Типовий сценарій: менеджер відфільтрував замовлення, відкрив одне, відредагував і повернувся до списку - фільтри на місці, а не скинуті.
Глобальні налаштування для всіх таблиць - у сервіс-провайдері:
use Filament\Tables\Table;
Table::configureUsing(function (Table $table): void {
$table
->persistFiltersInSession()
->paginationPageOptions([10, 25, 50]);
});
Пастки й нюанси:
- сесія і URL - різні речі. На сторінці списку ресурсу пошук, сортування, фільтри й групування й так синхронізуються з query string - таким посиланням можна поділитися. Сесія потрібна для іншого: щоб стан відновився, коли користувач повертається на сторінку без параметрів в адресі, наприклад через меню. У власних Livewire-компонентах з таблицею синхронізації з URL за замовчуванням немає;
- кілька таблиць на сторінці (основна плюс relation managers чи віджети) мають власні ключі стану. Для власних Livewire-компонентів з кількома таблицями знадобиться
queryStringIdentifier(), щоб параметри URL не конфліктували; - збережений фільтр може «загубити» записи: користувач відфільтрував, забув і через день думає, що даних немає. Помітні індикатори активних фільтрів і кнопка скидання тут дуже доречні;
- приховані колонки не потрапляють у вивід, але запит для них не змінюється - важкі агрегати в прихованій колонці все одно виконуються, якщо додані через
modifyQueryUsing.