Кто-Нибудь реализовывал фильтрацию листа с пагинацией? Стоит задача сделать окно со

списком с кучей фильтров по типу все/только тип 1/только тип 2 итд. Непонятно как в этом случае реализовывать подгрузку данных с сервера (могу пояснить проблемы которые я предрекаю если использовать 1 таблицу для всего). Единственное решение которое я вижу (которое мне косвенно так же предлагал работник гугла на issue трекере когда я задавал вопрос по сортировке paging листа по match info) это заводить под каждый фильтр отдельную таблицу со всеми вытекающим

Например, в запросе передавать параметры фильтра + размер и номер страницы. И пусть себе бэкенд работает.

Проблема в offline first и сохранении данных. Вероятные кейсы проблем если использовать одну таблицу для всего: Пока мы находимся во вкладке всё - все отлично, пагинация всегда работает правильно, но вот мы переключаемся на другой фильтр и доходим до конца списка. Имеем два пути, запросить с сервера всё с лимитом в 50 записей, их инсертнуть и надеяться что в них будет нужный нам тип айтемов, либо запросить 50 записей только с нужным нам типом. В первом случае может идти спам запросов потому что записей может быть например 2000 а нужного типа 60, причем например 30 в самом начале и 30 в самом конце. Во втором случае мы получим пропасть между данными потому что новые данные инсертнуться в бд. (потому что offline first и бд - single source of truth)

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

Что означает offline first в вашем случае? Нужно гуглить подобные решения. Вы не единственный у кого такая задача возникает. Наверняка для этого уже есть паттерн. Кроме того, набор данных с сервера и переключение туда-сюда между страницами UI - две совершенно независимые вещи.

То есть для каждого юзера будет создаваться таблица с результатами поиска по какому-то набору фильтров? А если начальство захочет изменить какой-нибудь фильтр (убрать/добавить критерии поиска), то это решение будет работать? Кто будет чистить старые результаты поиска на сервере? Как долго их хранить для конкретного юзера?

Причем тут сервер? Я про приложение все это время говорю. Сервер у меня фигурирует только как что-то что отдает данные по запросу

Откуда оно данные берет?

С сервера конечно, но манипулирует ими приложение

Ну, тогда тут два варианта: 1. Сервер разбивает всё на страницы по запросу от приложения, а приложение показывает готовый результат (кроссплатформенность) 2. Приложение само решает все вопросы с разбивкой данных (писать каждый раз отдельно для Android, iOS, web, etc, вносить изменения и глюки чинить - тоже)

Любой вариант где это будет решать сервер сразу отпадает, бекендер у нас не любит делать лишнюю работу а протолкнуть хоть что-то для удобства фронта целое достижение

Знакомая ситуация. Тады ой. Придется пилить толстый клиент со всеми вытекающими последствиями.

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

Такие появятся "когда в проект придут инвестиции" а пока только я, веб разработчик и он

Мдэ.

Веб-разработчик тоже должен такую пагинацию запилить на своей стороне, чтобы бэкенд отдыхал? 😄 Как быть с iOS?

Там веб - админка, не знаю что там. Любая моя критика апи заказчику всегда разбивается об очень опытный бэкэндер, его апи стоит в куче крупных предприятий и банках, оно очень крутое куча очень полезных нам функции (нет). Про iOS - пока вообще не думаем

До мудрого руководства нужно вежливо и аккуратно донести в письменном виде возможные риски клиентского решения. Критиковать никого не стоит, этого никто не любит. Просто выложить факты подтвержденные цифрами, например: - лишний трафик у клиентов, - возможная нехватка памяти==крэш на отдельных устройствах, потому что у Андроида их целый зоопарк и все протестировать невозможно - возможные проблемы с быстродействием на разных устройствах тоже по причине зоопарка, т.к. придется выполнять работу сервера на слабых устройствах - для такого опытного бэкендера не должно быть проблемой реализация дополнительной функции 😝 - iOS потребует в будущем повторной реализации этого функционала

Мне тоже нужно такой кейс( как в ютубе или в интернет магазинах