Комментарии 21
Соглашусь, что скроллинг в любое место списка из 10.000 записей — кейс скорее выдуманный. Однако, произвольный скроллинг в пределах 500–1000 записей — кейс живой.
… и с этого места становится непонятным, зачем велосипед. Таблица на 10 000 записей с сложной структурой строки — это тяжело и медленно, и действительно нужно комплексное решение. Но 10 000 записей никому нафиг не впилось пролистывать, как вы правильно заметили.
Таблица же на 1000 записей спокойнейше отработает без особого шаманства с виртуализацией, достаточно лишь ленивой подгрузки (то есть, ровно половину усилий от виртуализации).
Думаю инфинити скроллинг для нашего продукта тоже подошел бы (ленивая загрузка по мере прокрутки). Но есть справочники, в которых удобнее искать запись быстрой прокруткой в нужную часть списка (например, сотрудники, подразделения, города).
Возьмем, к примеру, 1С. В их справочниках же нет инфинити скроллинга, и думаю, если бы он появился, то использовать справочники стало бы менее удобно.
Возьмем, к примеру, 1С. В их справочниках же нет инфинити скроллинга, и думаю, если бы он появился, то использовать справочники стало бы менее удобно.
Но есть справочники, в которых удобнее искать запись быстрой прокруткой в нужную часть списка (например, сотрудники, подразделения, города).
Серьезно? Нет. Идеальным вариантом для вас было бы отучить людей «искать через скролл» и сделать хороший, быстрый, и легко юзабельный поиск, который бы на 1-2 буквы мгновенно бы сужал таблицу до вменяемого количества строк.
Но да, иногда бывает сложно противостоять запросам юзеров на кривые решения.
Мы закрыли одновременно два кейса: удобный поиск (он легко юзабельный, но не мгновенный), и кейс «искать через скролл»:
удобный поиск
Есть вариант не по вхождениям, а с начала строки? Есть по каждому столбцу отдельно?
Если есть, то согласен, что он у вас наверное удобный ^_^
Есть только по вхождениям и по столбцам.
Я б таки добавил с начала строки и где-то бы в метаданных это сконфигурировал: вещи типа ФИО, городов, и пр — гораздо эффективнее ищутся по началу строки. Даже наверное и юзеру не обязательно давать менять тип поиска.
Алсо, комплексные данные типа ФИО в одном столбце может быть имеет смысл давать искать раздельно (по Ф, И, О) — но это конечно уже зависит от ваших кейсов.
Алсо, комплексные данные типа ФИО в одном столбце может быть имеет смысл давать искать раздельно (по Ф, И, О) — но это конечно уже зависит от ваших кейсов.
Таблица на 1000 записей спокойно отработает и без ленивой подгрузки...
А никто не знает, что там будет у клиента, 1000 записей или 100000 записей.
Зависит от того, сколько понапихано в каждую строку. Задержки на рендер 1000 строк я своими глазами видел, на голом и очень быстро работающем js, вот чисто рендер долгий, из-за того, что каждая строка у нас была довольно монструозная.
У нас (в системе) есть две проблемы:
1. Дорого за раз выкачать 1000 записей (как по скорости, та и по объему передаваемых данных). Веб-сервер тратит 500 мс на формирование ответа в 100 записей, размер ответа = 200 Кб.
2. Дорого отрисовать за раз 1000 записей. У каждой строки очень сложна разметка (я писал про это выше).
По этому для нас оптимально выкачивать и отрисовать за раз 50-60 записей. А дальше выкачивать и рисовать по мере скроллинга.
1. Дорого за раз выкачать 1000 записей (как по скорости, та и по объему передаваемых данных). Веб-сервер тратит 500 мс на формирование ответа в 100 записей, размер ответа = 200 Кб.
2. Дорого отрисовать за раз 1000 записей. У каждой строки очень сложна разметка (я писал про это выше).
По этому для нас оптимально выкачивать и отрисовать за раз 50-60 записей. А дальше выкачивать и рисовать по мере скроллинга.
После прочтения статьи, хотел написать комментарий, но Вы сделали это за меня!
Полностью поддерживаю, что 1000 строк браузер отображает и скролит элементарно (без всяких виртуальных скролингов).
Осталось только понять, как эти 1000 строк отредерить изначально, чтобы не подвесить браузер на старте. Ленивая подгрузка — один из вариантов.
Полностью поддерживаю, что 1000 строк браузер отображает и скролит элементарно (без всяких виртуальных скролингов).
Осталось только понять, как эти 1000 строк отредерить изначально, чтобы не подвесить браузер на старте. Ленивая подгрузка — один из вариантов.
Ag-grid не смотрели? Виртуальный скрол, много чего умеет даже в бесплатной версии, большой простор для кастомизации, есть возможность (хоть и не так просто) интеграции с редуксом.
Не смотрели.
У нас в отделе прослеживается такая тенденция: берем стороннюю компоненту, понимаем что нас не устраивает ее внешний вид, поведение, работа с клавиатурой, фокусом, не хватает каких-либо возможностей. И начинаем все вылизывать, докручивать, переделывать в этой компоненте, учить ее работать с тем с чем она не умеет работать. И это не разовая работа, по ходу развития проекта появляются новые требования к уже используемым компонентам.
Это тоже сыграло роль в принятии решения.
У нас в отделе прослеживается такая тенденция: берем стороннюю компоненту, понимаем что нас не устраивает ее внешний вид, поведение, работа с клавиатурой, фокусом, не хватает каких-либо возможностей. И начинаем все вылизывать, докручивать, переделывать в этой компоненте, учить ее работать с тем с чем она не умеет работать. И это не разовая работа, по ходу развития проекта появляются новые требования к уже используемым компонентам.
Это тоже сыграло роль в принятии решения.
А сколько в итоге времени ушло на реализацию? И сколько человек это разрабатывало?
На прототипирование основных механизмов (виртуализация, работа с колонками, проционно загружаемые данные) потратили ~80 чч (человеко-часов). Два человека в течении недели полный рабочий день.
А затем составили детальный список всех работ, и это оказался очень большой список:
работа с redux, выделение, навигация, фокус, удаление-добавление записей, проверка инконсистентности, сокращение числа запросов при первом открытии, стили колонок/строк, работа с колонками (растягивание/перестановка/скрытие/сортировка/запрет перестановки), нет данных, выравнивание теста, триминг, контекстные меню, количество записей, поддержка автотестов, фильтры по колонкам, like-поиск, сохранение/восстановление настроек.
Все это делали долго, наверное, полгода. Примерно ~500 чч
В итоге по трудоемкости мы вложились сильно в грид. Компания нам такую возможность дала — отказаться от DevExtreme и все переписать.
А затем составили детальный список всех работ, и это оказался очень большой список:
работа с redux, выделение, навигация, фокус, удаление-добавление записей, проверка инконсистентности, сокращение числа запросов при первом открытии, стили колонок/строк, работа с колонками (растягивание/перестановка/скрытие/сортировка/запрет перестановки), нет данных, выравнивание теста, триминг, контекстные меню, количество записей, поддержка автотестов, фильтры по колонкам, like-поиск, сохранение/восстановление настроек.
Все это делали долго, наверное, полгода. Примерно ~500 чч
В итоге по трудоемкости мы вложились сильно в грид. Компания нам такую возможность дала — отказаться от DevExtreme и все переписать.
Хочется сказать отдельное спасибо за статью от команды DevExtreme. Такой фидбек о реальном использовании наших продуктов крайне ценен. Многие упомянутые проблемы мы сами видим, разделяем и планомерно устраняем. Совсем недавно мы добавили возможность использовать виртуальный скроллинг с ленивой загрузкой данных с сервера в нативный DevExtreme React Grid.
Также теперь мы даем из коробки React обертку для DevExtreme JavaScript DataGrid. В некоторых сценариях, трудности с управлением внутренним состоянием компонента действительно есть, работаем над этим :)
Также теперь мы даем из коробки React обертку для DevExtreme JavaScript DataGrid. В некоторых сценариях, трудности с управлением внутренним состоянием компонента действительно есть, работаем над этим :)
Еще бы примеров с кодом побольше выложили, а лучше сам грид в публичный доступ.
Тяжело понимать контекст.
Тяжело понимать контекст.
Давно хотим выложить грид в публичный доступ. Организационно проблем нет. Но есть проблемы с трудоемкостью: выделить его в отдельный проект, отвязать от нашей платформы, от завязок на некоторые компоненты (надо часов 50). Трудоемкость оценили, но времени нам пока на это не дали
Из альтернатив кроме ag-Grid есть ещё Bryntum Grid.
Приятно видеть, что DIRECTUM идет в таком направлении. И, особенно, что в статье даже ни слова о бренде не упонянуто.
С гридами в целом вообще беда, безкомпромиссных решений, где был бы набор всего, что в гриде требуется, вообще по ходу дела не существует (и в платных компонентах в том числе). Везде чего-то не хватает и приходится допиливать несвойственное поведение обходными путями. По рынку, ag-Grid, пожалуй, самый достойный из всех.
С гридами в целом вообще беда, безкомпромиссных решений, где был бы набор всего, что в гриде требуется, вообще по ходу дела не существует (и в платных компонентах в том числе). Везде чего-то не хватает и приходится допиливать несвойственное поведение обходными путями. По рынку, ag-Grid, пожалуй, самый достойный из всех.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Зачем писать свой React Data Grid в 2019