Comments 37
Что подразумевается под виртуальным скроллингом? Подгрузка дополнительных данных при прокрутке до конца страницы?
В общем работаю над аналогом phpMyAdmin, для чего написан свой datagrid на JS, пока там реализован обычный постраничный пейджинг. Но стало интересно насколько востребован виртуальный скроллинг.
Для тех кто не в курсе, при виртуальном скроллинге данные загружаются тоже небольшими частями как и при постраничном пейджинге, но полоса прокрутки при этом рисуется такой, как будто в гриде показаны все данные. Когда вы скроллите софт берет инфу о смещении прокрутки, и загружает соответствующую порцию данных.
Т.е. получается компромиссный вариант, с одной стороны используется малое количество памяти и время на реддеринг, с другой получаем удобство навигации почти, как с обычным скроллингом (можно тыкнуть в любое место, работает кнопки и колесико мышки для скрола, проще визуально оценивать в какой части таблицы находишься и т.п.).
Для тех кто не в курсе, при виртуальном скроллинге данные загружаются тоже небольшими частями как и при постраничном пейджинге, но полоса прокрутки при этом рисуется такой, как будто в гриде показаны все данные. Когда вы скроллите софт берет инфу о смещении прокрутки, и загружает соответствующую порцию данных.
Т.е. получается компромиссный вариант, с одной стороны используется малое количество памяти и время на реддеринг, с другой получаем удобство навигации почти, как с обычным скроллингом (можно тыкнуть в любое место, работает кнопки и колесико мышки для скрола, проще визуально оценивать в какой части таблицы находишься и т.п.).
такой вариант разве будет быстро работать?
В принципе не медленнее постраничной навигации. Но можно некоторые фишки применять, типа небольшого дополнительного буфера и упреждающего чтения, в таком случае юзер вообще может не замечать, что что-то там подгружается.
Здесь включается субъективное восприятие. Когда мы листаем страницами, то нас будет удовлетворять задержка в 1-2секунды (даже большая не станет критичной, для пользователя), когда у нас идет динамическая загрузка при скроллинге, то такая задержка смотрится противоестественной, ощущение, что система тормозит, намного больше.
ИМХО для интранетовских проектов, которые не нагружены сильно — такой вариант имеет смысл, в определенных ситуациях, использовать. Иначе — это либо пэйджинг, либо то, как делается в соц.сетях сейчас, с «показать еще», зависит от задачи и объемов данных.
ИМХО для интранетовских проектов, которые не нагружены сильно — такой вариант имеет смысл, в определенных ситуациях, использовать. Иначе — это либо пэйджинг, либо то, как делается в соц.сетях сейчас, с «показать еще», зависит от задачи и объемов данных.
конечно быстрее… либо у вас в dom тысячи тегов, из-за которых браузер съест не мало памяти, а ОС будет страницы памяти писать на винт и при скроллинге вы будете ждать свой винт… либо у вас пару десятков тэгов, которые ничего не весят… даже слабинький проц с перерендерингом 2х десятков тэгов справится на ура…
в виртуальном скроллинге главное реализовать: выделить всё, выделить часть(которая больше видимой) и естественно копировать, быстрый переход на 1523 строку, возможность табличку раздвоить и видеть рядом две разные части таблицы, ну и другие фишки которые устранят недостатки постраничного просмотра
в виртуальном скроллинге главное реализовать: выделить всё, выделить часть(которая больше видимой) и естественно копировать, быстрый переход на 1523 строку, возможность табличку раздвоить и видеть рядом две разные части таблицы, ну и другие фишки которые устранят недостатки постраничного просмотра
кстати можно показывать 2 десятка элементов, а хранить в виде объекта например 1000, что займёт много меньше памяти, чем уже отрендеренное в DOM
var table = [
{
'user_id': 12254,
'login': 'ddv'
},
{
'user_id': 12255,
'login': 'Fedcomp'
},
{
'user_id': 12256,
'login': 'zapimir'
}
];
var table = [
{
'user_id': 12254,
'login': 'ddv'
},
{
'user_id': 12255,
'login': 'Fedcomp'
},
{
'user_id': 12256,
'login': 'zapimir'
}
];
Я долго думал над вопросом.
Так как с одной стороны виртульный скроллинг это круто, с другой, мы теряем такую ценную вещь как подвал и навигацию там.
Плюс, не всем он нужен это скроллинг. С другой стороны иногда нужно пользоваться CTRL-F или подобным поиском.
Поэтому ИМХО, в идеале нужно комбинировать:
1) Первые 2 страницы подгружаются виртуальным скроллингом.
2) Потом, появляется большая кнопка (Загрузить еще)
3) На кнопке еще пару контролов:
— Загрузить все
— перейти на страницу.
Так мне видится в идеале.
Считаю, что страничную навигацию (или ее аналог) нельзя убивать.
Так как с одной стороны виртульный скроллинг это круто, с другой, мы теряем такую ценную вещь как подвал и навигацию там.
Плюс, не всем он нужен это скроллинг. С другой стороны иногда нужно пользоваться CTRL-F или подобным поиском.
Поэтому ИМХО, в идеале нужно комбинировать:
1) Первые 2 страницы подгружаются виртуальным скроллингом.
2) Потом, появляется большая кнопка (Загрузить еще)
3) На кнопке еще пару контролов:
— Загрузить все
— перейти на страницу.
Так мне видится в идеале.
Считаю, что страничную навигацию (или ее аналог) нельзя убивать.
Не совсем понял про поиск. При постраничной навигации же не выводится вся таблица, для поиска в любом случае лучше использовать средства БД для этого, а не средства грида.
Убивать пейджинг в принципе не собираюсь, тут скорее наоборот, стоит ли рожать виртуальный скроллинг.
Вот для наглядности, что такое виртуальный скроллинг на примере:
mleibman.github.com/SlickGrid/examples/example-optimizing-dataview.html
Убивать пейджинг в принципе не собираюсь, тут скорее наоборот, стоит ли рожать виртуальный скроллинг.
Вот для наглядности, что такое виртуальный скроллинг на примере:
mleibman.github.com/SlickGrid/examples/example-optimizing-dataview.html
Смотря сколько желания делать поиск.
Браузерный СTRL-F получает очков 100 за поиск.
Примитивный поиск по БД 50. Хороший, 150. Подумайте, если смысл развивать поиск в Вашем случае;)
Или проще остаться при «Select ALL» а дальше пользователь уже сам как его душе угодно ищет.
Стоит ли рождать? Смотря что делаете. Если обёртку для мускула, то лично я (лично я) такой потребности не вижу.
Браузерный СTRL-F получает очков 100 за поиск.
Примитивный поиск по БД 50. Хороший, 150. Подумайте, если смысл развивать поиск в Вашем случае;)
Или проще остаться при «Select ALL» а дальше пользователь уже сам как его душе угодно ищет.
Стоит ли рождать? Смотря что делаете. Если обёртку для мускула, то лично я (лично я) такой потребности не вижу.
Ответ на это.
Хабраглюк.
Хабраглюк.
Боюсь Select ALL на табличке в несколько сотен тысяч записей заставит сильно задуматься браузер, а бывают таблички и значительно больше. Хотя ради интереса нужно будет потестить, сколько строк в таблице браузеры выдержат.
а зачем? грид сам спрашивает у data provider-а нужные строчки, сам их рисует, и сам прибивает то, что не влезает в окно просмотра. даза банных получает запросы вида LIMIT X,Y и радуется. только не используйте без нужды ORDER BY и всё будет быстро и хорошо.
Да тест то чисто из спортивных интересов, понятное дело что не буду делать в конечном продукте, чтобы в грид грузилась здоровая таблица ;) А насчет ORDER BY это уже не от меня зависит, а от юзера.
виртуальный скроллинг генерит намного больше паразитных запросов к базе, чем пагинация, потому что при скроллинге их возникает много и часто. и вообще юзеру будет очень нравиться эта фича и он будет туда-сюда по табличке елозить по делу и без дела. так что ORDER BY надо запрещать где только можно, особенно если по полю индекса нет) в крайнем случае ругаться и говорить «ой вей, вы таки понимаете какой вы поц? [OK] [Cancel]»
Если не обратили внимания, этот грид я собираюсь использовать в современном аналоге phpMyAdmin, как вы себе представляете запрет админу отсортировать данные как он хочет? ;)
Что касается паразитных запросов, тут всё зависит от реализации. Понятное дело, что не будет делаться так, чтобы при скролле на строку вниз делался запрос в MySQL, а при скролле назад на строку вверх делался еще один запрос. Это всё решается довольно просто, к примеру, на экране выводится 50 строк, а из MySQL при этом достается скажем 500 строк, при скроллинге в пределах этих 500 строк никаких запросов к MySQL, запрос будет сделан когда юзер пролистает 450 строк.
Что касается паразитных запросов, тут всё зависит от реализации. Понятное дело, что не будет делаться так, чтобы при скролле на строку вниз делался запрос в MySQL, а при скролле назад на строку вверх делался еще один запрос. Это всё решается довольно просто, к примеру, на экране выводится 50 строк, а из MySQL при этом достается скажем 500 строк, при скроллинге в пределах этих 500 строк никаких запросов к MySQL, запрос будет сделан когда юзер пролистает 450 строк.
не изобретайте велосипеды, в dojo давно есть мощный грид для этого дела. он очень быстр даже на огромных датасетах. впрочем, на квазильонах строк я его не тестил :) www.sitepen.com/blog/2008/11/21/effective-use-of-jsonreststore-referencing-lazy-loading-and-more/ — в этом примере упор сделан на in-memory storage, но экстраполиоруется для любого источника данных.
далее:
1. навигация в подвале становится не нужна. вообще.
2. кнопки «загрузить ещё» имеют смысл в контактиках и фейсбучиках, а если у вас датасет на 30000 строк — вас будет это бесить.
3. Ctrl-F это прекрасно, но имеет смысл только если на страницу влезли все данные. чтобы искать по датасету (или гриду), нужно использовать заточенные под это дело механизмы и встроенные в грид фильтры. в любом случае при классической постраничной навигации Ctrl-F будет отдыхать.
лично моё мнение: виртуальный скроллинг — это бобро. аминь.
далее:
1. навигация в подвале становится не нужна. вообще.
2. кнопки «загрузить ещё» имеют смысл в контактиках и фейсбучиках, а если у вас датасет на 30000 строк — вас будет это бесить.
3. Ctrl-F это прекрасно, но имеет смысл только если на страницу влезли все данные. чтобы искать по датасету (или гриду), нужно использовать заточенные под это дело механизмы и встроенные в грид фильтры. в любом случае при классической постраничной навигации Ctrl-F будет отдыхать.
лично моё мнение: виртуальный скроллинг — это бобро. аминь.
Что касает датагрида в Dojo, я посмотрел здесь dojotoolkit.org/reference-guide/dojox/grid/DataGrid.html
мне он показался глючноватым, так же у него излишнее количество DOM-элементов, там каждая строка это отдельная таблица в DIV'е.
В общем это касается не только датагрида в Dojo, а и других. В них вроде много реализовано, но много косяков во всяких мелочах. К примеру раздражает, что во многих гридах, где есть инлайновое редактирование, скачет высота строки в которой редактируешь ячейку, ну блин, неужели, так сложно сделать по-людски.
Или как в том же Dojo когда редактируешь ячейку там открывается выпадающий список, так вот в Firefox 8, не выделяются пункты этого списка при наведении, при этом стоит убрать мышку на таблицу, так начинают подсвечиваться строки, ну это же вообще халтура.
Так что насмотрелся я этих датагридов много, потому и написал свой велосипед, где я могу отшлифовать все мелочи, чтобы они работали правильно, а не сделаны кое как, лишь бы работало.
мне он показался глючноватым, так же у него излишнее количество DOM-элементов, там каждая строка это отдельная таблица в DIV'е.
В общем это касается не только датагрида в Dojo, а и других. В них вроде много реализовано, но много косяков во всяких мелочах. К примеру раздражает, что во многих гридах, где есть инлайновое редактирование, скачет высота строки в которой редактируешь ячейку, ну блин, неужели, так сложно сделать по-людски.
Или как в том же Dojo когда редактируешь ячейку там открывается выпадающий список, так вот в Firefox 8, не выделяются пункты этого списка при наведении, при этом стоит убрать мышку на таблицу, так начинают подсвечиваться строки, ну это же вообще халтура.
Так что насмотрелся я этих датагридов много, потому и написал свой велосипед, где я могу отшлифовать все мелочи, чтобы они работали правильно, а не сделаны кое как, лишь бы работало.
на данный момент наилучшим способом навигации по таблице является метод под названием «Что такое виртуальный скроллинг?»
виртуальный скроллинг хорош, когда неторопливо читаешь анекдоты в ленте.
А когда смотришь конкретные данные всегда возникают задачи позиционирования, которые сложно реализовать нормально, например банальный скролл в конец.
На самом деле важнее иметь хороший поиск, лучше даже instant.
А когда смотришь конкретные данные всегда возникают задачи позиционирования, которые сложно реализовать нормально, например банальный скролл в конец.
На самом деле важнее иметь хороший поиск, лучше даже instant.
Похоже вы не тот скроллинг имеете ввиду. Вот еще один пример.
Никаких проблем со скролом в конец нет, тупо опустил ползунок вниз до упора, и в грид загрузились данные находящиеся в конце таблицы.
Никаких проблем со скролом в конец нет, тупо опустил ползунок вниз до упора, и в грид загрузились данные находящиеся в конце таблицы.
Вообще зависит от задачи.
Если страниц меньше десятка — виртуальный скроллинг подойдет.
Если страниц меньше десятка, данные табличные, и пользователю может пригодиться Ctrl+F, то имеет смысл грузить всю таблицу сразу.
Если у вас сотни страниц, и пользователю действительно может захотеться обратиться к ним (например, bash.org.ru), то имеет смысл делать нумерованную пагинацию.
В общем же случае, если у вас есть многостраничные таблицы, то нужно прежде всего озаботиться поиском. Пользователь должен увидеть нужную информацию в 1-3 клика.
Если страниц меньше десятка — виртуальный скроллинг подойдет.
Если страниц меньше десятка, данные табличные, и пользователю может пригодиться Ctrl+F, то имеет смысл грузить всю таблицу сразу.
Если у вас сотни страниц, и пользователю действительно может захотеться обратиться к ним (например, bash.org.ru), то имеет смысл делать нумерованную пагинацию.
В общем же случае, если у вас есть многостраничные таблицы, то нужно прежде всего озаботиться поиском. Пользователь должен увидеть нужную информацию в 1-3 клика.
проголосовал за «Виртуальный скроллинг»
но вообще для такой задачи как аналог phpMyAdmin, я бы сделал подгрузку аяксом только при явном запросе, например, при нажатие псевдо-ссылки «показать ещё страницу результатов»
т.е. чтобы при пролистывании вниз страницы ничего внезапно не появлялось.
но вообще для такой задачи как аналог phpMyAdmin, я бы сделал подгрузку аяксом только при явном запросе, например, при нажатие псевдо-ссылки «показать ещё страницу результатов»
т.е. чтобы при пролистывании вниз страницы ничего внезапно не появлялось.
Зачем делать лишнее движение мышкой, когда без этого можно обойтись?
В топе ЖЖ как раз так сделано — очень удобно.
В топе ЖЖ как раз так сделано — очень удобно.
Это уже вопрос реализации, для того чтобы внезапно не появлялось, достаточно выбирать данные с запасом, и при приближении к концу этого запаса делать упреждающее чтение. Т.е. в таком случае когда вы доскроллите до конца блока, то новые данные уже будут загружены. А видно как загружаются дополнительные данные будет по сути только в случае когда вы сделали «прыжок» на большое расстояние к примеру сразу в конец таблицы.
Я даже небольшую статейку писал на тему того, как я реализовывал свой грид (для аналога PhpMyAdmin это было бы кстати): habrahabr.ru/blogs/algorithm/111422/. Если кому-то очень хочется, я даже могу дать свою реализацию такого грида с виртуальным скроллом.
Sign up to leave a comment.
Какой вариант навигации по большой таблице считаете предпочтительным?