Архитектура фильтров для каталогов и рейтингов
Для каталогов и рейтингов Murino я вынес повторяющуюся логику фильтров в общие функции. У каждого раздела остались свои поля и правила запросов к Strapi.
Личная зона ответственности
Мой вклад
Здесь перечислена выполненная мной работа в рамках задачи, а не авторство всего продукта или результат всей команды.
- Спроектировал общую архитектуру фильтров для каталогов и рейтингов.
- Разделил UI, состояние фильтров, сериализацию параметров и запросы к Strapi.
- Настроил предсказуемую работу поиска, сброса фильтров и пагинации.
Один портал должен был обслуживать несколько разных сценариев поиска.
Задача по архитектуре фильтров
На портале Murino были каталоги жилых комплексов, школ, детских садов, ресторанов, фитнес-клубов и медицинских центров. Страницы выглядели похоже, но у разделов различались поля, связи в CMS и условия фильтрации.
Нужно было связать элементы фильтра, выбранные значения, URL, пагинацию и REST-запросы к Strapi. При добавлении раздела хотелось описывать его параметры, не копируя весь механизм поиска.
Почему обычных фильтров было недостаточно
В одном разделе нужны категория и район, в другом — текстовый поиск или сортировка. При переходе на следующую страницу выбранные условия должны сохраняться. Поиск не должен отправлять запрос после каждой введённой буквы.
Я вынес хранение состояния, сериализацию параметров и задержку поиска в общую логику. Формирование запроса к Strapi учитывало поля конкретного раздела.
Как было устроено решение
Я отделил повторяющиеся части от специфики разделов. UI-контролы отвечали за ввод, состояние фильтров - за текущие значения, а слой запросов собирал параметры для Strapi. Это позволило не смешивать в компонентах карточек знания о том, как именно CMS ожидает фильтры и связи.
Для поиска использовался debounce, чтобы интерфейс оставался отзывчивым и не создавал лишние запросы. Сброс фильтров и смена страницы были вынесены в отдельные действия, потому что они меняют контролы, набор данных, URL и состояние пагинации.
- Общая логика фильтров для разных каталогов и рейтингов
- Отдельная работа с UI, параметрами и API-запросами
- Понятная передача значений в Strapi и URL
Что важно учитывать в такой архитектуре
Такой подход не отменяет необходимость понимать каждый каталог отдельно. Если у раздела появляется особая связь в CMS или нетипичная логика отображения, ее все равно нужно описывать явно. Зато базовые вещи - поиск, сброс, пагинация, составление запроса - перестают расползаться по страницам.
Общими остались поиск, сброс и пагинация. Поля и связи задавались для каждого каталога отдельно.
Что дало это решение проекту
Поиск, сброс и пагинация стали общими для каталогов и рейтингов. Особые поля и связи остались в настройках разделов. Новые категории можно было подключать без копирования всей логики фильтрации.
Границы общей логики фильтров
Я бы не стал заранее делать универсальный фильтр для любых данных. В этом проекте хватило общих действий и отдельных настроек разделов: так различия между каталогами оставались видны в коде.
Проверяемые детали и ограничения
Материалы проекта
Что можно проверить по материалу
- На изображении показан реальный экран каталога городского портала.
- В материале перечислены конкретные части решения: состояние фильтров, URL-параметры, debounce, пагинация и REST-запросы к Strapi.
- Роль и личный вклад отделены от результата проекта в целом.
Что осталось за рамками
Исходный код и внутренняя схема CMS не публикуются. Скриншот подтверждает пользовательский интерфейс, но не служит независимым доказательством внутренней архитектуры.
Стек
Проекты, где применялся этот опыт
Подробнее о проектах: задача, интерфейс и выполненная работа.
Связанные услуги
Если у вас похожая задача, посмотрите состав работ и порядок оценки.