Pull to refresh

Comments 30

Если фильтровать значения, то высота не пересчитывается - остается пустой скролл, в какой-то момент отвалились PgUp, PgDwn

У меня один вопрос - для чего на экране пытаться отображать 1 млн строк? Пусть даже с быстрым скроллом и поиском? Вы представляете - какой это объем данных нужно сформировать и передать? Там на этом этапе все зависнет уже и помрет

Например, чтобы все закешировать локально и ходить за данными в память, а не в сеть?

И если данные одной строки поменялись в БД, то начинай сначала. Выборка с фильтрами из БД будет быстрее, чем та же самая фильтрация на фронте.

Обычно, если вы открыли курсор в какой-то момент времени, то вы не увидите через него изменений, сделанных после этого момента. Во всяком случае, на умолчальных уровнях изолированности.

Что-то сомневаюсь, что будет быстрее сделать запрос в сеть, выполнить на стороне БД выборку с фильтрацией, возможно с чтением с диска, сериализовать, отправить обратно по сети, десериализовать, чем просто сделать фильтрацию в памяти на клиенте (естественно, предполагаем, что там не линейный поиск по миллиардному массиву, а какой-то индекс).

Ну и особенно, если вам нужно часто менять данные на фронте, а они сильно связанные (например, граф какой-нибудь). Вместо того, чтобы на каждое изменение записывать это в БД, можно редактировать все локально, а потом записать все изменения скопом, еще и послав только финальный diff.

Если вам нужно оперативное обновление данных то врядли вам нужно миллион строк. По моей практике такие большие выборки это консистентный слепок на какой то момент времени и с ним работают, ну типа за какой то прошлый период.

Я в статье не увидел конкретно этой идеи. Поправьте, если я не прав.

Зачем отображать блок в 15кк пикселей я могу предположить. Тут речь скорее всего не идёт об отрисовке сразу всех строк, наверное, это какой-то фикс для скрола плюс "виртульный скрол". Мол много строк и это должно отображаться на скролбаре. Пользователь должен иметь возможность потянуть его курсором мышки в любое место списка и т.д.

О, js-программисты таки изобрели виртуализацию. Not bad, not bad...

Осталось теперь дождаться решения задачи с редактированием первой, последней и строчкой посередине.

Это легко не перестраивать DOM, а просто обновлять ячейки "одинакового", замечу, размера. Этим вы никого не удивите.

А когда у вас внезапно появляется состояние, которое надо хранить у невидимых ячеек, тогда вы и вспомните этот комментарий. Никому не надо скроллить по миллиону записей, а редактировать (привет, Excel), фильтровать, сортировать - это всегда нужно.

Состояние которое надо хранить уже есть - это данные ячеек.

Хранить - это мало, надо это восстанавливать, и учитывать, как я уже сказал, сортировку и фильтрацию.

Вы можете со мной спорить, защищая ваш грид, но я бы сказал так - в нём нет ничего для меня нового. Я это видел 10 лет назад… и судя по комментариям не только я. Я лишь вам сказал, чего у вас не хватает и с чем вы ещё не сталкивались.

Спасибо за комментарий.
Конечно гридам 100 лет.

Пока не вижу в чем сложность получить значение в ячейке. Это уже сделано - что-бы нарисовать ячейку нужно получить её значение.

Будут трудности, буду решать.

Я тоже этим занимался, и у таких решений есть два серьезных недостатка. Первый - нет горизонтальной виртуализации, почему-то никто не учитывает сценарий, когда мы открываем на миллион строчек и 5 столбцов, а миллион строчек и 1000 столбцов. А второй - если ячейки должны быть разной высоты - все поплывет.

чувак , ты реально задолбал уже всех рекламой своего $mol'а. Если честно, кроме негатива уже ничего не вызывает

Слыш, Юрик УЙ, ты рили заколебал уже задалбываться. Иди ка ты лучше по ссылке лонгрид читкани - поймёшь как взрослые пацаны виртом занимаются. А то разфантазировался тут про свой $mol - в каждой дырке он уже мерещится.

А если, скажем, не миллион, а тысяча строк, будете все честно отрисовывать?

больше гораздо) просто человек очевидно не интересуется ни js, ни веб-разработкой, но зайти и кинуть какаху в js - святое дело. вы ничего не объясните такому и не докажете)

Обиженный смузихлеб детектед хДД

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

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

В демо классно поиск работает. Вводишь слово в поле поиска, текст фильтруется, а ячейки как были отрисованы, так и остались. Только данные из них стерлись)

Как это работает с элементами у которых высота блока ничем не ограничена?

На телефоне скролл работает странно - скролится быстрее, чем я двигаю пальцем.

Я в своей библиотеке вообще не читаю дом, а храню текущие значения в легковесном кэше. Чтобы можно было быстро проверить изменились ли они и если поменялись то обновить только изменившиеся значения.

Есть миллион объектов в памяти - допустим. Отсортировал, отфильтровал, пол ляма осталась - допустим. А дальше я знаю, что в высоту моего экрана входит 10 контейнеров. Не 1, не 100, не пол ляма в доме мне не нужны. 10, Карл ) Мне не нужно их шевелить, мне не нужно их скроллить. Ни удалять из дом, ни добавлять. Мне всего лишь нужно знать, на каких 10 объектах из пол ляма отсортированных сейчас фокус. Теми данными контейнеры и заполняю. Ну пусть у меня ещё экранный скролл на пол пальчика появится, потому что у этих 10 объектов слишком много букав. Пусть живёт своей жизнью по 10 контейнерам.

Спасибо за статью. Заставило задуматься.

И все же я удивляюсь, человек сделал исследование выложил все, разжевал. А налетела куча комментаторов, а зачем да так не комильфо и т.к. далее... Автор реально проделал огромную работу и сделал быстрый интерфейс, дал готовое решение с комментариям, а у нас тут же налетела куча критиков и все плохо да и то не так и вообще...

Sign up to leave a comment.

Articles