Как лучше сохранить фильтрацию/сортировку на странице после сохранения/апдейта?

Question

[vism]

Суть задачи.
Обычный CRUD. На странице фильтры, сортировка. Нужно сделать запоминание фильтров/сортировки после редактирования, создания и т.п.
Варианты которые вижу я.
1) Фильтры в сессию - самый очевидный и самый говнокодерский, с проблемами при поддержке.
2) URL с гет параметрами в сессию - Насколько я понял в ларавель поддержки из коробки нет. URL::back() и прочее работает на 1 переход, а если при редактировании были ошибки и страница перезагружалась или несколько страниц пошагового редактирвоания, возврат на индекс страницу не работает, в back содержится не тот урл
3) открывать в другом табе - не юзер френдли.

Вопрос.
Может есть отличный, работающий паттерн решения данной задачи. Может удобный компонент.

Comments

[Максим Федоров]

может на фронтенде решить вопрос? LocalStorage?

[vism]

Максим Федоров, Да я тоже думал, как-то на фронтенде, но тут не современный продукт) рендеринг всего и вся через сервер каждый раз

Answer 1

[ThunderCat]

Да я тоже думал, как-то на фронтенде, но тут не современный продукт) рендеринг всего и вся через сервер каждый раз

vism, куки, и ничего не мешает при запросе из куки достать переменную, которую вы бы тянули из базы/сессии. Кроме того - сессия привязывает эти настройки к текущему подключению, куки же будут доступны и после релогина. В базе такое хранить - это редкое гонево, это настройки отображения, и я могу их менять в зависимости от устройства с которого захожу на сервер, это гораздо удобнее. с мобилы удобен один вид, с десктопа другой, в большинстве случаев.

Answer 2

[Александр Талалаев]

А как ты запоминаешь личные данные юзера? Например Имя, или пароль?
Тут такой же подход. Делать таблицу с сохранением настроек пользователя.
Кстати это один случаев когда удобно хранить в формате json, в постгресе даже есть спец поле для этого, впрочем в mysql можно в текстовом/строков хранить, врядли вы будете это поля использовать для поиска.
А при загрузке страницы просто разбирать json(его наверное удобнее использовать если у вас активно js и ajax используется), либо читать все значения из соответсвующей таблицы и расставлять в шаблонизаторе.
Сама таблица/структура json подбирается уже исходя из того как у вас вообще релизованы поля, глянь так же сюда. Этот механизм например активно используют ребята из Spatie , например в их продукте Laravel Permission, где есть проблема когда не знаешь куда к какому типу будут вешаться значения.

Comments

[vism]

Ну по сути сессия/бд/кэш.
Проблемы все те-же. Какая разница какое хранилище.
Проблема сохранения, разборки данных. куча кода, проблемная поддержка.

[vism]

так уж хранение УРЛа в сессии по ключу с подменой при обращении в голому выглядит проще в реализации и поддержке, в десятки раз проще

[ThunderCat]

впрочем в mysql можно в текстовом/строков хранить, врядли вы будете это поля использовать для поиска.

Поддержка json в мускуле весьма себе неплохая, в том числе и для поиска.

[Александр Талалаев]

vism, куки хуже, стерл куки настройки провали. БД привязка непосредственно к пользователю независимо от устройства и тд. Иногда совмещают эти способы, все зависит от сценариев. Кода совсем немного, если изначально "фильтры" для поиска еще и по уму спроектированы, с автоматическим формированием из свойств объектов, то можно грубо говоря один раз все закодить, а потом все будет автоматом работать.

[alex-1917]

Александр Талалаев, а типичный покупатель стирает куки каждый божий день или даже каждый месяц?))) покажите мне такого!

[Александр Талалаев]

alex-1917, я же отметил что зависит от сценариев, просто если учитывать что работа может вестись с разных устройствах. Вы же не написали ваши пользовательские сценарии. Вот например с CRM это может быть актуально, запоминать так фильтры. Во многих случаях и для магазина тоже, к тому же опять таки даже хранение/кеширование этих данных может происходить по разному. я лишь описал один из возможных, который не так плох и достаточно универсален, и при правильном подходе легко написать универсальный обработчик, которому будет почти не важно где и как ты хранишь, но это уже отдельная история.
И естественно для вашего случая возможно лучше подойдет другой.

Answer 3

[alex-1917]

Я в таких случаях (когда чего-то не знаю) иду и копошу движок, например если для магазина, то беру парочку магазинных и потрошу, причем тут лара вообще не понятно))) писать настройки списка товаров в БД???? ооооооо
Берем опенкарт - штатный шаблон смотрит - если есть в сессии - берет оттуда, если нет ищет в локалсторадже, если нет ни там ни там, то пишет опять же проверяя доступна ли сессии или локалсторадж, т.е. офигенно универсальная схема и без всяких БД)))
Битрикс - пишет или в сессию или куки или в LS - на 100% зависти от шаблона
HostCMS - LS

Так и не понял, зачем выше советовали хранить в БД??? зашел с того же устройства - куки или LS тут как тут! - ВСЁ!

Answer 4

[Александр N++]

Storejs если фильтр подумаете сохранять через js