Добрый день.
Есть задача.
Рендер больших списков и таблиц(имеется в виду от 1 000 000 записей) в браузере.
Десктопные UI тулкиты её решают ondemand рендерингом видимого окна, например (QML ListViewModel) .
Какова, на ваш взгляд, наилучшая клиентская библиотека которая помогает решить этот случай.
Спасибо.
-----
Интересно так-же, как вы бы решили проблему с удаленными запросами и кешированием.
В данный момент, единственное что приходит в голову, это использовать lifo стек, и таймаут по последнему запросу к индексу.
Что-то типа, если скролл не скроллил последние N миллисекунд то
достать M последних запросов на рендер элемента и выполнить их.
Таким образом мы избегаем переполнения буффера в случае скроллинга из начала в конец(1 000 000 ajax запросов, если делать тупо ondemand)
on-demand подразумевает загрузку данных чанками, скажем по 1000 штук.
Что до описываемого вами кейса с прокруткой из начала в конец - если мы резко переходим - это будет один запрос. Если мы плавно скролим - мы можем загружать данные большими чанками и все будет так же плавно и хорошо, пока мы проскролим пару тысяч айтемов данные для следующего чанка так же загрузятся.
Тут намного интереснее реализация виртуального скрола. Рекомендую вам искать готовые ибо самостоятельно у вас написать оный хоть и выйдет - вы убъете на это безумное количество времени.
Что до описываемого вами кейса с прокруткой из начала в конец - если мы резко переходим - это будет один запрос.
----
Простите, каким образом?
У нас в каждый момент скролла есть некоторое окно с текущими элементами.
Если мы проскроллили в конец( или, в любую другую точку), это означает, что это окно было отрендерено N/M (где M индекс элемета, N размер страницы) раз, пусть и очень быстро(например, плейсхолдерами).
Я нашел следующее решение. Допустим мы прокрутили к X и остановились(нет скролла N миллисекунд), достать все индексы X-10..X и запросить дату. В случае если скролл продолжился, то запрос нужно как-то прервать(открытый вопрос)
Ваше решение с чанками я не понял, поясните пожалуйста.
Забыл упомянуть. Если вы говорите в контексте lazy loading pagination, то это не подходит.
Нужна честная навигация в N элементах в том объеме который не держит браузер.
Lazy loading, я понимаю как тупое добавление нового чанка даты в конец списка по событию конца скролла.
mik222: ок, допущение моей реализации - фиксированная высота элемента. А если это так - то нет никаких проблем вычислить какие элементы нужны на каком уровне скрола. То есть если мы просматривали последний последнию часть данных, и потом резко так ткнули скрол в начало списка - мы точно знаем с какого по какой элемент нам надо отображать и мы можем загрузить только то что нужно сейчас + запас для более плавного скрола. Так же по тому как долго и в какую сторону мы скролим мы можем примерно предсказать что надо будет показывать.
