Сабжем никто не занимался случаем?

Как решали?

грузить асинхронно порциями, какие еще могут быть варианты

какая связь между NodeJS и скроллингом таблиц?
NodeJS - серверный код.

(1) Варианты в определении нужной порции.

(2) В этом и смысл. БД Постгрес. Через курсоры? А как обновлять. Как синхронить с клиентом?

(4) в том то и дело, что (2)

(5) Если сервер отправит на вебклиента сразу всю таблицу и далее скроллить средствами броузера или js в нем то будут тормоза.
Задача сделать отзывчивый интерфейс.
Чтобы да вебсервер (nodejs) отдавал данные из базы для вебклиента (HTML5 броузер) нужными порциями.
Причем какую порцию отдавать еще и "предвидел" по поступающим командам-запросам данных с клиента.

(4) при прокрутке до 80% записей клиент запрашивает с сервера новую порцию и получив закидывает в таблицу

(7) Это если простейше. А хочется упредить. Чтобы в фоне подгрузка шла. Но без лишнего.
А куда старые данные. Для прокрутки назад. Как определять старость.

Т.е. может у кого уже есть подобный опыт.

(8) запоминать начальную и конечную строку полученного набора, при прокрутке назад выбирать меньшие значения чем начальный номер
В фоне и будет идти пока пользователь оставшиеся 20% записей будет докручивать

есть подход когда каждая следующая порция в 2 раза больше предыдущей, тогда реже приходится обращаться на сервер. И в 1С вроде такой же способ

(9) (10) ОК.
А если сортировка по полям таблицы. Сортировать на сервере? Как после сортировки текущей строкой сделать эту же. Или пофиг и сбрасываем.

Потом поиск по полю. Тоже на сервере сразу искать и нужный кусок отправлять?

Понятно что с отбором попроще. Кстати так и делал давно просто показ первых 100 записей и далее отбор на сервере.

Хорошая задачка для программиста.
Я бы повозился. Но таблица - таблице рознь.

(11) условия отбора и сортировки передавать на сервер, конечно

я забил и сделал без динамической подгрузки: http://fragster.ru/perfomanceTest/results.php
но вообще экспериментировал с отправкой на клиента размера (для рисования скролла) и текущего "фрэйма" + два "фрэйма" в обе стороны. Когда запас в какую-то сторону становился меньше одного фрэйма - подсасывал новые данные асинхронно. при этом дергать скролл можно было в любую сторону на любое расстояние - он показывал некоторое время пустую табличку, а потом в ней подгружались данные. ноде для этого не обязателен, работало на хттп-сервисах 1с + сериализация json

Можно конечно послать изучать код реализации ТабличногоПоля и ПоставщикаДанныхODBC в 1С++, но это очень жестоко.

А так - согласно REST серверу вообще должно быть пофиг, что на клиенте.
Клиент должен посылать запросы, в которых указывать, которая порция данных ему нужна. Сервер должен выполнить запрос и вернуть данные. А вот как оптимально написать запрос, который получит именно порцию данных - это уже надо смотреть в каждом конкретном случае.
В 1С++ это решалось тем, что всегда был уникальный ключ упорядочивания в запросе, а клиент передавал значение ключа и направление выборки.
Например, получение справочника с сортировкой по наименованию:
Первый запрос, клиент не передает ключ:
select from ttt order by descr, id limit 100
Клиента скроллят, нужны данные, последний полученный ключ - "Варежки", 23
select from ttt where descr>'Варежки' or (descr='Варежки' and id>23) order by descr, id limit 100
Клиента скроллят в конец:
select from ttt order by descr desc, id desc limit 100
Клиента скроллят перед 'яблоки', 113
select from ttt where descr<'яблоки' or (descr='яблоки' and id<113) order by descr desc, id desc limit 100

Но не знаю, сможет ли постгресс правильно оптимизнуть эти условия и попасть в индекс.

Блин, из-за звёздочек курсив включился.

https://datatables.net/examples/ajax/simple.html
хороший бесплатный JS Фреймворк для табличек, таких полно.
но это на фронте. Есть примеры со скролом.

(17) JS UI  фреймворком с гридами много.

Но хочется то нечто вроде как на vaadin
https://vaadin.com/elements/-/element/vaadin-grid
Lazy loading a large data set - ленивая загрузка из больших источников данных

(18) Там другой риск, будет подтягивать много данных - у браузера может оперативки не хватить. А принцып тот-же.

(19) Старые данные нужно из памяти броузера того. Потом если что снова.

Ну и как ты устаревшие данные отличишь от актуальных?

вон ваадин говорит, что реюзинг дом, так что проблемы старых данных не должно быть

(21) По времени их непоказа на экране.

(23) не вариант, можно очень быстро скролить

кстати почему собственно ваадин не берешь?

(16) тест
не курсив * курсив * не курсив

(24) Скорость скроллинга можно учесть. Как параметр для старения.

(25) Попробую vaadin elements. Вдруг что другое есть.

(26) Это работает только у модераторов

А по-моему скроллинг - зло. Сразу проблема с простановкой точной ссылки и поиском, если содержимое будет индексироваться.

(29) Не понял. А понял. Раздел/секцию поменяли. Был "Убийцы 1С".

Проблему для броузера решил.
В https://vaadin.com/docs/-/part/elements/vaadin-grid/datasources.html есть

grid.items = function(params, callback) {
  setTimeout(function() {
    callback(employees.slice(params.index, params.index + params.count));
  }, 400);
};
grid.size = employees.length;

На сервер буду передавать params.index (верхний видимый) и params.count (количество видимых).
Сервер по последовательности их заранее (упреждающее чтение) подготовит данные из БД. Далее будет отсылать сразу готовые данные без запроса к БД.

Еще можно сделать кэш на JS в броузере. В виде массива полученных данных. Куда складывается все пришедшее с сервера. И грид будет слайсить из этого кэш массива.

(31)+ Осталось придумать алгоритмы для сервера. По таблице ВремяЗапроса|ИндексНачальнойСтроки|КоличествоСтрок.
Предсказывать следующие данные которые будут запрошены.