Comments 17
загрузку и визуализацию до миллиона спанов на нашей странице детализации трассировок.
Оптимизация вывода и вывод миллиона span - это разные вещи. Так-то такой метод оптимизации вывода известен давно. Вот один из хороших примеров реализации: https://github.com/6pac/SlickGrid и я про этот компонент знаю лет 15, кажется.
Похвально , конечно, но React, div… что-то тяжеловатое выбрали. Имхо Webgl здесь подойдет, можно начать хотя бы с D3.js…
Начать стоило всё же с $mol, где виртуализация сложной вёрстки есть из коробки. Вот, например, список из миллиона адаптивных форм в 150 простых строчках кода. Забавный факт: этот список в высоту в 3 раза больше, чем ограничение Хрома на высоту скроллящейся области (2**25), так что домотать до конца его не получится.
В мобильном Chrome ваша реализация работает крайне криво.
Ага, Хрому сносит крышу при таких больших скроллах. Уменьшите число элементов раза в 3 (в левой панели) и всё станет нормально. Сафари так вообще падает.
В мобильном хроме нет ни левой, ни правой панели, только то, что видно на видео. Свайпы влево-вправо (помню вы такое любите делать) тоже не помогают
Это какая-то лютая бага в Хроме. Фрейм с атрибутов srcdoc и наличием скроллбара внутри, не выпускает события скролла наружу. В проде всё нормально (@1dNDN там 100к сейчас).
@RulenBagdasis там была указана не правильная минимальная высота строк. Сейчас такого не должно быть.
Конечно в проде нормально, у вас там 10 000 записей, а не миллион
В Хроме еще скрол иногда сбрасывается если повозить мышкой туда-сюда: https://youtu.be/wWml587wpS8
Миллион форм заканчивается примерно на 90к, но пустота скроллится весьма эффективно, да...
Обычно если просят вывести миллион, значит не знают что надо
Мы можем рендерить только те спаны, которые находятся во вьюпорте пользователя.
Что не просто логично, а я бы даже сказал - напрашивается. Даже странно, что эта идея так редко востребована, и до си пор сохраняет элемент новизны. Лет 20 назад мы решали похожую (но другую) задачу - отобразить на интерактивном рисунке много-много миллионов значений данных. Решение получилось примерно в том же духе: мы отображаем на экране не весь массив, а только то, что видит пользователь. С учетом наложения элементов и рамки просмотра. И динамически пересчитываем картинку при рендеринге. В качестве бонуса это еще и позволяет нам при экспорте рисунка в векторный файл получать картинки вменяемого размера. Только мы тогда не знали тех модных слов, которыми изобилует статья, и по рабоче-крестьянски назвали это
генерализацией изображения
Кстати, этот проект - программа для анализа временных рядов геодинамического мониторинга - до сих пор жив. Правда, там куча кода, поэтому если кому-то интересны подробности, проще не копаться в исходниках, а посмотреть основные идеи в справке программы. Файл называется WinABD_Help.chm , там подразделы 3.2.1.9, 3.2.6.1 (a) и др.
Для хранения и извлечения данных телеметрии мы используем столбчатую базу данных.
Да-да, у нас тоже столбцы, только с временными рядами. И СУБД собственной разработки - родом из 1980-х., но до сих пор в продакте. Хотя и пережила за это время пару модификаций ;-)
Забавно. Лет 30 назад это были вполне очевидные паттерны. А читаешь статью, будто они всё это заново изобрели. Ну или как будто статья написана в году этак 1996.
Все потому что сейчас фреймворки учат, а не паттерны. Но справедливости ради я не помню чтоб 30 лет назад js что-то на лету генерил в зависимости от того, что во viewport. Даже календариков таких не помню, чтоб несколько месяцев вверх, несколько вниз и эффект бесконечного скрола был ) Надо виртуалку на основе zvercd win xp поднять и попробовать там современный веб открыть 😁
Не понятно, что нового изобрели? Например в extjs такой механизм для грида вроде бы.
Прочитал заголовок - задался вопросом "на хрена?"
Прочитал статью - задался вопросом "на хрена?"
Вопросом как им это удалось не задаюсь
Проектируем веб-страницу, отображающую миллион элементов