Комментарии 17
Всем привет! Меня зовут Аня Ланда, я фронтенд-разработчик в Самокате. В компании я больше двух лет, общий стаж во фронтенде – 6 лет и всё это время я делаю таблицы
А зачем это в статье, для этой информации на хабре есть страница профиля.
Очень ждал подробностей, как именно в конце концов проблема больших таблиц решилась переносом логики на бэкенд - но не дождался :(
Ибо 40-90 тысяч строк - это полбеды, а вот миллионы строк, по которым пользователь должен на лету строить сводные таблицы... Нашёл в своё время под эту задачу готовое платное решение (готовый микросервис на .NET + фреймворконезависимый код для фронта), приготовился заплатить - но испытать в деле не получилось, т.к. тот проект заглох, до написания фронтенда не добравшись. Удивило, что в open source ничего даже близко не нашлось, все pivot tables, как одна, хотели сразу загрузить все данные на фронт. А писать такое с нуля - нетривиально, для маленького проекта не вариант.
Когда-то давно обожглись на сводных таблицах на DOM элементах - всё сильно тормозило у пользователей.
В итоге нашли опенсорс https://pivotgrid.js.org/demo.html добавили своей логики на js и с сотнями тысяч позиций взлетело.
А агрегаты, да - на фронте считать не стоит.
Именно в том проекте, с которого всё начиналось, на бэк пока перенесли только группировку. Все понимают, что надо бы и фильтрации, и сортировки перетащить, но этот проект - очень неповоротливая махина, да еще и очень чувствительная для бизнеса. Так что в нем с наскока взять и переписать всё пока невозможно (именно по бизнесовым причинам). Но я писала, что в новом проекте с более или менее похожими запросами мы это сделали. Теперь там всё супер легко и просто. Даже и рассказать-то нечего)
Так, сортировка, подсчёты, фильтрация и даже группировка — остаются на фронтенде.Не шарю в терминологии – вы подразумеваете сортировку таблицы «на сотни тысяч строк» браузером/другим клиентом?
А зачем менять Angular на React?
А какой смысл переходить с angular на react?
Так и не понял о чем статья, обычная работа фронта. А переход с ангуляр на реакт (по крайней мере с контекстом из статьи) вообще ничем не обоснован...
Вообще интересная статья, но я все ждал рассказа, как вы боролись с адаптивом, но так и не дождался (поставщики заходят в приложение только с десктопа?). В одном из своих проектов на реакте я пилил кастомный хук, который меняет тип компонента в зависимости от диагонали экрана (с таблицы на перечень карточек), т.к. очевидно что на мобилке совершенно невозможно с большими таблицами работать...
В случае, когда нужен адаптив - можно использовать вместо таблиц гриды. Каждая строка, как отдельный грид контейнер. Из минусов, с гридами у нас может чуть поехать ширина столбцов в разных строках придётся поиграть со стилями, чтоб этого избежать. Зато из плюсов то, что адаптив, можно будет целиком сделать на css, при помощи медиазапросов.
Я для нашей библиотеки таблички и state managment к нему делаю. Там уже где-то 5 лет это все эволюционирует потихоньку.
Чтобы поддержать строки разной высоты - от контента зависящей - сделали свою виртуализацию. Все виртуализируют тупо расставляя строки абсолютом, и высчитывая координаты каждой - так не катит.
Загрузка данных с сервера - чтобы подгружало и вниз и «вглубь» - тоже ну очень непросто. Особенно если есть всякие cascade selection.
Редактирование - вроде и просто, но нюансов тьма. У нас многие компоненты умеют mode=cell, и можно всякие DatePicker-ы вставлять в ячейки.
Сейчас вот делаем копирование ячеек перетягиванием как в excel. И удобное API для subtotals.
И думаю еще раз попробовать переверстать все с флексбоксов на css grid - потому что народ начал хотеть мерджить ячейки вертикально, на текущей верстке это нормально не сделать.
Короче с таблицами большой опыт, могу поделиться.
Очень странно что для таких больших таблиц никто не упомянул о react-virtualized пакете с его рендрером только тех записей которые видны, так же есть уже готовый react-data-grid, но тут есть сложности с адаптацией под свои нужды? Если бы использовали что-то из указанного выше могли бы и миллионы записей показывать на фронте.
А я читаю: Я решила использовать что-то новое, возникли проблемы и МЫ всей командой начали думать, как исправить эти проблемы ))
А так: сложный фронт - горе в команде. Тем более, что сложный фронт в web. Лучше режим виртуализации + обсчитывающая хотелки пользователей бэковая часть
Эволюция подходов к работе с таблицами во фронтенде