Как стать автором
Обновить

Комментарии 16

Как часто надо расставлять анкоры? Я правильно понимаю, что это какая-то псевдо-виртуализация? Для каждой строки таблицы создаётся контейнер, и для каждой n-ной добавляется якорь для нотификации о появлении на экране? А не поздновато ли рендерить, когда элемент уже на экране? И как это будет работать с миллионами строк?

Можно вообще не расставлять — блок с контентом position relative, нижний ватермарк — position absolute, bottom 200px (или какой буфер вам надо) его и обсервить.

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

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


Видел до 300к строк в таблице. Хотя очевидно, что пользователь в любом случае будет фильтровать, нежели искать по алфавиту (но если забрать у них такую возможность и не предложить ничего другого адекватного, будет кипиш).

Нее, то, что пользователь работает с данными на миллионы строк это и так ясно. Вопрос в том, в какой задаче нужно именно в браузер тащить такие объемы. Даже при инфинит скролле пользователь физически не наскроллит объем более чем в несколько тысяч строк (думаю, что в реале до 1000, дальше будет фильтровать). Т.е. просто нужна качественная серверная фильтрация.
Конечно, есть задачи, в которых надо одновременно отображать несколько тысяч элементов: пример из того, с чем в последнее время работаю — таймлайн с отображением расписания, где на экране можно показать примерно 5-7К элементов за раз, но там и в ширь и в высь они идут, их можно воспринимать в таком объеме. Для грида нетормозной скролл на 5К элементов мне видится вполне достаточным. Всё имхо.
Зачем тогда создавать таблицу с бесконечной прокруткой?
> написать много логики в обработчике прокрутки, чтобы предотвратить слишком частую перерисовку, так как каждый коллбэк скролла будет вызывать setState.

lodash.debounce

Скорее throttle

Хм, да, для прокрутки таблицы пожалуй throttle.

Это все равно ухудшит пользовательский опыт. Если вы добавите листнер на скролл, особенно если это НЕ passive listener браузеру придется дожидаться ответа от JS на каждый скролл что ухудшит плавность скроллинга. Даже если этот листнер будет просто делать return потому что он затроттлен. Подход с IntersectionObserver на имеет влияния на плавность скролла.


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


Да большую часть этих проблем можно решить сделав, например класс который аккамулирует триггеры которые могут привести к необходимости догрузки данных и проверяет реальную необходимость через requestAnimationFrame + использовать только passive листенеры стролла и ресайза, но тогда вы фактически изобретете IntersectionObserver.

Ногами не пинайте, но чем это лучше pagination с фильтром?
Во-первых, тренд. Во-вторых для развлекательного контента удобнее (пример на том же пикабу можно глянуть). Для аналитики или других серьезных вещей пагинация будет удобнее.
Тем, что правильная реализация загрузки части контента(для продолжения старницы), будет всегда намного быстрее загрузки всего контента на новой странице
А зачем для паджинации новая страница? Данных можно грузить ровно столько же сколько и при инфинит скролле.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории