Comments 30
Если фильтровать значения, то высота не пересчитывается - остается пустой скролл, в какой-то момент отвалились PgUp, PgDwn
У меня один вопрос - для чего на экране пытаться отображать 1 млн строк? Пусть даже с быстрым скроллом и поиском? Вы представляете - какой это объем данных нужно сформировать и передать? Там на этом этапе все зависнет уже и помрет
Например, чтобы все закешировать локально и ходить за данными в память, а не в сеть?
И если данные одной строки поменялись в БД, то начинай сначала. Выборка с фильтрами из БД будет быстрее, чем та же самая фильтрация на фронте.
Обычно, если вы открыли курсор в какой-то момент времени, то вы не увидите через него изменений, сделанных после этого момента. Во всяком случае, на умолчальных уровнях изолированности.
Что-то сомневаюсь, что будет быстрее сделать запрос в сеть, выполнить на стороне БД выборку с фильтрацией, возможно с чтением с диска, сериализовать, отправить обратно по сети, десериализовать, чем просто сделать фильтрацию в памяти на клиенте (естественно, предполагаем, что там не линейный поиск по миллиардному массиву, а какой-то индекс).
Ну и особенно, если вам нужно часто менять данные на фронте, а они сильно связанные (например, граф какой-нибудь). Вместо того, чтобы на каждое изменение записывать это в БД, можно редактировать все локально, а потом записать все изменения скопом, еще и послав только финальный diff.
Если вам нужно оперативное обновление данных то врядли вам нужно миллион строк. По моей практике такие большие выборки это консистентный слепок на какой то момент времени и с ним работают, ну типа за какой то прошлый период.
Я в статье не увидел конкретно этой идеи. Поправьте, если я не прав.
Зачем отображать блок в 15кк пикселей я могу предположить. Тут речь скорее всего не идёт об отрисовке сразу всех строк, наверное, это какой-то фикс для скрола плюс "виртульный скрол". Мол много строк и это должно отображаться на скролбаре. Пользователь должен иметь возможность потянуть его курсором мышки в любое место списка и т.д.
О, js-программисты таки изобрели виртуализацию. Not bad, not bad...
Осталось теперь дождаться решения задачи с редактированием первой, последней и строчкой посередине.
Раскройте мысль
Это легко не перестраивать DOM, а просто обновлять ячейки "одинакового", замечу, размера. Этим вы никого не удивите.
А когда у вас внезапно появляется состояние, которое надо хранить у невидимых ячеек, тогда вы и вспомните этот комментарий. Никому не надо скроллить по миллиону записей, а редактировать (привет, Excel), фильтровать, сортировать - это всегда нужно.
Состояние которое надо хранить уже есть - это данные ячеек.
Хранить - это мало, надо это восстанавливать, и учитывать, как я уже сказал, сортировку и фильтрацию.
Вы можете со мной спорить, защищая ваш грид, но я бы сказал так - в нём нет ничего для меня нового. Я это видел 10 лет назад… и судя по комментариям не только я. Я лишь вам сказал, чего у вас не хватает и с чем вы ещё не сталкивались.
Я тоже этим занимался, и у таких решений есть два серьезных недостатка. Первый - нет горизонтальной виртуализации, почему-то никто не учитывает сценарий, когда мы открываем на миллион строчек и 5 столбцов, а миллион строчек и 1000 столбцов. А второй - если ячейки должны быть разной высоты - все поплывет.
Давайте я попробую удивить: https://mol.hyoo.ru/#!section=docs/=gjboo1_xhyrnq
чувак , ты реально задолбал уже всех рекламой своего $mol'а. Если честно, кроме негатива уже ничего не вызывает
А если, скажем, не миллион, а тысяча строк, будете все честно отрисовывать?
Уже лет десять как https://github.com/bvaughn/react-virtualized
больше гораздо) просто человек очевидно не интересуется ни js, ни веб-разработкой, но зайти и кинуть какаху в js - святое дело. вы ничего не объясните такому и не докажете)
15-20 лет назад
Виртуализация (таблицы, бесконечные ленты и др.) может сильно навредить в плане доступности. Пока нет ничего лучше, чем классическая пагинация.
В демо классно поиск работает. Вводишь слово в поле поиска, текст фильтруется, а ячейки как были отрисованы, так и остались. Только данные из них стерлись)
Как это работает с элементами у которых высота блока ничем не ограничена?
На телефоне скролл работает странно - скролится быстрее, чем я двигаю пальцем.
Я в своей библиотеке вообще не читаю дом, а храню текущие значения в легковесном кэше. Чтобы можно было быстро проверить изменились ли они и если поменялись то обновить только изменившиеся значения.
Есть миллион объектов в памяти - допустим. Отсортировал, отфильтровал, пол ляма осталась - допустим. А дальше я знаю, что в высоту моего экрана входит 10 контейнеров. Не 1, не 100, не пол ляма в доме мне не нужны. 10, Карл ) Мне не нужно их шевелить, мне не нужно их скроллить. Ни удалять из дом, ни добавлять. Мне всего лишь нужно знать, на каких 10 объектах из пол ляма отсортированных сейчас фокус. Теми данными контейнеры и заполняю. Ну пусть у меня ещё экранный скролл на пол пальчика появится, потому что у этих 10 объектов слишком много букав. Пусть живёт своей жизнью по 10 контейнерам.
Спасибо за статью. Заставило задуматься.
И все же я удивляюсь, человек сделал исследование выложил все, разжевал. А налетела куча комментаторов, а зачем да так не комильфо и т.к. далее... Автор реально проделал огромную работу и сделал быстрый интерфейс, дал готовое решение с комментариям, а у нас тут же налетела куча критиков и все плохо да и то не так и вообще...
JavaScript. Как сделать невероятно быстрый многопоточный Data Grid на 1 000 000 строк. Часть 1/2: нюансы работы с DOM