Как архитектурно сделать подгружаемые списки?

Question

[SirotaKazansky]

Есть backend, есть frontend.
Фронт отображает список чего угодно, транзакций например. Транзакции он берет с бэка.
Транзакций очень много, тянуть сразу все записи на фронт не хочется, поэтому решено подгружать их частями, по мере скролла вниз по списку.

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

Вопрос : может быть есть типовые решения как сделать юзеру удобно и как это архитектурно запланировать (на уровне методов сервисов)?
Пока есть мысль отдать бэку id той записи, на которой в списке стоял юзер, ну или она была в середине видимой части, и запросить "окно" списка таким образом, чтобы эта запись оказалась в том же месте на экране.

Answer 1

[Robur]

но получается что новые подгружаемые записи не сортированы или отсортированы иначе чем выбрал юзер

Что вам мешает при запросе транзакций с бека так же отправить с запросом нужную сортировку, чтобы новые записи были отсортированы так же?

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

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

Answer 2

[SirotaKazansky]

Мы конечно отправим нужную сортировку, и постраничным выводом подгружаем. Проблема в другом, возможно я не точно объяснил.

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

Answer 3

[xmoonlight]

В несколько этапов:
1. Запрос на сортировку и саму активную запись (id) в позиции "курсора" (или порядковый номер позиции сначала всего списка, если вдруг нет активного "курсора") отправляем на бэк.

2. Делаем запрос сортировки/фильтрации в БД и сохраняем текущий результат выборки во временное хранилище.

3. На фронте, по готовности: забираем сразу список элементов относительно местоположения "курсора" в "окне отображения" (или количества элементов от начала списка), который полностью помещается в это "окно".

4. По мере прокрутки, забираем куски выборки с бэка аяксом (наборы элементов "окна отображения"), расположенные выше или ниже. Этот приём называется "виртуальное окно".

Comments

[SirotaKazansky]

Вот это как раз то решение, о котором я говорил в исходном посте (внизу). Может еще какие-то пути сделать юзеру удобно?:) Ну может что-то вроде быстрого возврата к предыдущей сортировке типа "я ошибся, верните как было, где моя самая нужная запись была!!!".

[xmoonlight]

SirotaKazansky, ну нужен бэк - держите также историю аякс-запросов на сервере.
Остальное - всё уже есть в моём ответе.

PS: Повторю ещё раз для более полного понимания...
Навигация - по id записи (или порядковому номеру строки относительно начала всего выводимого списка) и смещению виртуального "окна" (скролл списка) относительно начала всего выводимого списка.