Комментарии 57
Важно, чтобы обработчик вызывался самым первым, чтобы никто не успел до него внести изменения в DOM. Тогда размеры и координаты элементов будут браться максимально быстро — из кеша. Поэтому, следующим шагом мы пробегаемся по всем интересным нам элементам и получаем их габариты.
Вроде бы самый сомнительный пункт. Если дом уже инвалидирован к моменту исполнения первого колбэка, то запрашивая баунд рект мы сделаем полный цикл рендера, а последующий колбэк из раф очереди затрэшит всю эту работу установкой какой-нибудь трансформы для анимации.
Это может работать только, если все действия с домом выполняются на уровне фреймворка и никто кроме фреймворка не трогает дом и не лезет в раф.
Возможно я где-то не прав.
Если успеть прокутить скрулбар несколько раз, до загрузки контента, то после загрузки он «прыгает».
эм, та вообще не проблема оптимизировать. другое дело что производители не видят в этом проблемы, необходимости видимо) тут же в этом больше нюанс) почему сайты позволяют делать себе неоптимальные решения, к примеру тот же ютуб?
Потому что нанимают "Senior React Developer" по объявлениям.
о, видите Дмитрий. вот тут ваша компетенция заканчивается и начинается ресёрч на тему ведения бизнеса) что бизнес считает проблемой, а что не считает. чтобы уметь смотреть на вещи не только глазами разработчика, а и предпринимателя, и дизайнера и т.д.
Ну да, и в РЖД кто угодно может влезть в сеть за 20 минут потому, что там умеют смотреть глазами предпринимателя, дизайнера и тд.
«Надо мной будут смеяться, но я — человек смелый, поэтому скажу: нужна разделяемая и обществом и государством… идеология. Любая. Ещё десять лет духовной нищеты и буду согласен даже на монархию… Только честную, пожалуйста. Без бутафорий. Дуэли тоже верните. И всем получившим высшее образование — личное дворянство автоматически.
После формирования идеологии формируется нечто большее чем жалкая „теория игр“, в рамках которой „живи сам и дай жить другому“. Появляется возможность выращивания не только профессионального этикета, но и высших (т.е. вне зависимости от мнения начальника) норм поведения.»
таблицы гораздо менее затратны в плане сложности вычислений для браузера чем обычные блоки
Нет конечно. Только с table-layout: fixed, что превращает таблицу в набор колонок фиксированной ширины (его прекрасно можно сделать и другими способами, сейчас не 2001 год).
Таблицы с авто-лейаутом не "менее затратны", а строго наоборот, т.к. чисто по спецификации рендер каждой новой строки может начать заново рендерить всю часть таблицы до этой строки.
Надо, кстати, сравнить мою реализацию флоу таблиц с нативной. Моя делает это за 4 фиксированных фазы, без пересчётов сначала. Флоу обычных параграфов мне удалось сделать в 2 раза быстрее нативного.
Я бы не назвал flexbox "обычными блоками", с которыми вы сравнили таблицы. Флекс действительно небыстр, когда надо выводить очень много контента, но при большой сложности одного элемента расходы на то, чтоб уложить 10+К таких элементов флексом — перестают иметь какое-либо значение, узкое место не там.
Не знаю может я что-то делаю не так ну у меня в моём приложении чата 10000 сообщений чата рендерятся за пару секунд и довольно плавно скролятся
А вы попробуйте открыть его на мобилке.
Странно, я может тоже что-то не так делал, но react-virtualized, о котором вы вскользь упомянули, у нас исправно работает 4 года. Листает 100 000 элементов как папа. Да, был момент, мы приделали к нему адаптер для динамического преобразования деревообразных структур в плоские списки с отступом и... Виоля...
100%-ный React, никаких разбродов, метаний, шатаний, стенаний...
ЗЫ. Вот на гитхабе даже что-то осталось: demigor/react-treegrid
Печать сломана, сохранение в файл сломано, поиск слова не подсвечивает
Слова всё же подсвечиваются, а вот печать, да, надо починить. В режиме печати виртуализация должна отключаться, а сколлящиеся области должны выключать скроллинг.
Касательно печати — это был баг. Виртуализация-то отключалась, но упомянутые в выступлении оптимизации предотвращали пересчёт лейаута. Я его починил и добавил слайд про печать: https://github.com/nin-jin/slides/blob/master/virt/readme.md#%D0%BF%D0%B5%D1%87%D0%B0%D1%82%D1%8C
Уже прочитав заголовок я снова задался вопросом — хочу ли я, чтобы на хабре был virtual scroll в комментариях. И быстро пришёл к выводу — НЕТ. Потому что его сложно реализовать хорошо. Я занимался такими задачами и хорошо помню чего это стоило. Выводы и грабли на которые я наступил — примерно как в статье. Никогда не понимал почему nin-jin так топит за virt. scroll, учитывая сколько там подводных камней и какой поганый в итоге получается результат. У всех, не только у nin-jin
В первую очередь подумал о поиске. Больная тема. Сразу много нюансов. К тому же одна из самых важных для опытных пользователей. Открыл демку. Попробовал поскролить. Выделил произвольный текст. Вбил в поиск. Увидел что система вместо того, чтобы обеспечить около-нативное поведение зачем-то отрезала мне кусок от комментариев и скрыла всё остальное. Даже дочерний комментарий уже посмотреть нельзя. Ну думаю, ладно, может сейчас я кликну на нужный комментарий и снова вернусь в общее древо. Ан нет. Не могу. Ладно, не беда — нажму "крестик" в поиске и останусь на той же позиции. Ан нет. Не остался.
Ну и зачем такие комментарии? Только потому, что они не тормозят? Я подожду уж эти 10-15 секунд. Да неприятно. Но в результате я могу пользоваться страницей. А в этой демке — не могу.
Правда стоит отметить, что эта проблема решаема. Я когда, реализовывал поиск, просто обеспечивал скролл к нужному элементу с учётом отступов (чтобы элемент не был прибит к краю).
Пока остаюсь при старом мнении — virt. scroll это всегда компромисс. Очень больной компромисс. Не стоит использоваться его без большой нужды. Для этого нужны серьёзные обстоятельства.
P.S. понравилось название "кенгуру". Я это называл "crude scroll". По сути сколлинг был двух видов:
- soft: когда просто рендерим всё честно, всё что проскроллили и с небольшим резервом. После рендера кадра — образаем лишнее. Получается плавный и приятный опыт
- crude: когда угадываем где примерно оказался бы пользователь при честном скролле и рисуем кадр сразу оттуда. Насколько хорошо мы угадаем зависит от того насколько хорошо были подсчитаны размеры. А это целая наука :)
система вместо того, чтобы обеспечить около-нативное поведение зачем-то отрезала мне кусок от комментариев и скрыла всё остальное
Задача не "околонативное" поведение обеспечить, а помочь пользователю найти то, что он ищет. Один из вариантов — скрытие нерелевантного, что и было реализовано в этой демке.
Даже дочерний комментарий уже посмотреть нельзя.
Можно. Слева от сообщения есть экспандер.
не беда — нажму "крестик" в поиске и останусь на той же позиции. Ан нет. Не остался.
Это, как раз, из-за того, что я DOM меняю и привязка скролла подавляется. Отключил фильтрацию, теперь такого не происходит.
Ну и зачем такие комментарии? Только потому, что они не тормозят? Я подожду уж эти 10-15 секунд. Да неприятно. Но в результате я могу пользоваться страницей. А в этой демке — не могу.
На этот вопрос я отвечал в самом начале выступления. Вы же нашли в одной демке (из двух представленных) маленький изъян, который никто больше не заметил, и который легко устраняется за пару минут, и сделали из этого глобальные выводы.
Проблем там куда больше чем описанная выше. Просто поиск у меня больная тема. Вот сейчас ещё раз открыл вижу что вы там кастомный скролл реализовали. Это тоже одна из таких вещей, который в здравом рассудке делать не стоит. Потому что всегда получится плохо. Вот и на этот раз. На кой чёрт он такой крошечный? Снайперов готовить? А ведь очень просто оставить обыкновенный, нативный для платформы, куда более продуманный. Я так понимаю вы скроллбаром не пользуетесь, и поэтому он такой… маковский. Apple кажется scrollbar-ы вообще не признаёт (к счастью его ещё можно включать в настройках).
Но вернёмся к поиску. При больших объёмах данных это очень важный инструмент. Как я писал выше, я бы предпочёл чтобы virt. scroll-а не было вовсе, чем когда он есть, но с ним нет хорошего поиска. Я тысячи раз пользовался им в комментах, пытаясь найти нужную позицию. Это к я тому что изъян отнюдь не маленький. Если бы я был заказчиком я бы запросил удалить всю эту самодеятельность. Вы назвали её "скрытие нерелевантного". При том что по сути скрыли релевантное. Человек когда ищет комментарий — очень часто ищет его как якорь. Вроде: "это был рядом с комментарием про майонез".
После исправления стало сильно лучше. Теперь поиском пользоваться, хотя и немного неприятно, т.к. очень ненативное поведение, но можно. Теперь он стал решать поставленные перед ним проблемы. Из мелочей: Подсветка найденного на скроллбаре отсутствует. Scroll прыгает к искомому не плавно (по понятным причинам). F3 не работает. Отступа между искомым и краем viewport-а нет. Режет глаз. Выделение искомого, имхо, опять же очень странное. Браузер найденное выделяет жёлтым фоном (кажется он ещё и в контрастность умеет). У вас это непривычный розовый текст. Браузер умеет искать по одной букве. Поисковая строка в браузере "не прыгает" пока в неё вбиваешь буквы. И не тормозит так сильно. При этом поиск происходит сразу, а не по Enter. Ну и т.д.
Стоит отметить кое в чём такой поиск лучше хромовского — он не "нормализует" букву "ё" в букву "е" :) Кстати, вы учли нормализацию при поиске? Там есть свои отдельные подводные камни.
Почти всё из вышеописанного (всё, кроме наверное F3) можно исправить. Но это надо поприседать. В частности выделение на скроллбаре — не самая тривиальная штука. Отсюда мой изначальный довод в силе: virt. scroll это почти всегда очень большой компромисс, т.к. он имеет очень много недостатков. И его не только не нужно делать по-умолчанию (бедные пользователи), а вообще стоит применять только там где без этого ну никак. Ну либо когда вы готовы сражаться до последнего и всё равно дать немного посредственный результат. Когда я делал нечто подобное (у меня правда задача была сложнее из-за огромных таблиц с чудовищными rowSpan-ми), я хорошо понимал зачем я это делаю: была нужда редактировать 900+ A4 страничные законы\бюджеты\whatever. Там вопрос стоит между: не делать вовсе, либо делать с virt.scroll-ом. Выбора нет.
Здесь же ситуация спорная. На мобильниках virt.scroll скорее нужен, чем нет. Но на мой взгляд там придётся решать ещё 1 проблему: вложенные комментарии через большие отступы абсолютно неюзабельны в вертикальной раскладке. Там нужен вообще другой интерфейс. А на десктопе получается странная штука, которую надо полировать и UX всё равно будет совсем ненативным. И не факт что по итогу не полезут браузерные проблемы :D
P.S. "который никто больше не заметил" — это очень печальный факт.
вижу что вы там кастомный скролл реализовали
Это нативный скролл с изменёнными стилями скроллбара.
Кстати, вы учли нормализацию при поиске?
Неа, что ввели — то и ищется.
кроме наверное F3
Это, как раз, просто. Уже добавил.
В частности выделение на скроллбаре — не самая тривиальная штука.
Да вроде не особо сложная. Список найденного есть. Осталось получить оценки их позиций и нарисовать линейку. Впрочем, штука не очень полезная.
Отступа между искомым и краем viewport-а нет.
Это из-за того, что высота контента от края вьюпорта до найденного не определена заранее (например, картинка ещё не загружена) и может оказаться больше вьюпорта и сместить найденное за пределы видимой области.
Браузер найденное выделяет жёлтым фоном (кажется он ещё и в контрастность умеет). У вас это непривычный розовый текст.
Браузерный жёлтый часто не вписывается в цветовую тему страницы. Розовый — это акцентный цвет в светлой теме по умолчанию сейчас, но я думаю его поменять на более яркий. В тёмной теме как раз жёлтый. Кстати, обратите внимание, что нерелевантный текст немного приглушается.
Браузер умеет искать по одной букве.
Нет никакой проблемы искать по одной букве, но и смысла тоже нет.
Поисковая строка в браузере "не прыгает" пока в неё вбиваешь буквы.
Зато закрывает часть страницы. Вообще, странно сравнивать демку, интерфейс которой сделан за 5 минут, с продакшен реализацией в браузере.
И не тормозит так сильно.
Ввожу "пр". Моя реализация выдаёт результат через пару секунд. Нативная прыгает секунд 10.
Ввожу "пр". Моя реализация выдаёт результат через пару секунд. Нативная прыгает секунд 10.
Проверил. Да, ваш сильно тормозит, но суммарно работает куда быстрее. Стандартный не тормозит совсем, но индексирует очень долго. Полагаю не помешает async поиск. Получится почти также быстро, но ещё и отзывчиво.
Розовый — это акцентный цвет в светлой теме по умолчанию сейчас, но я думаю его поменять на более яркий
Рекомендую, даже если хочется оставить розовый, то сделать его фоновым. Так горааздо привычнее.
Это из-за того, что высота контента от края вьюпорта до найденного не определена заранее (например, картинка ещё не загружена) и может оказаться больше вьюпорта и сместить найденное за пределы видимой области.
Да нет же. Оно так систематично работает. Пиксель в пиксель к рамке. Но да, это конечно мелочь. Этой штуки кстати сильно не хватает и в стандартном барузерном API вроде плавного скролла. Плюс браузер скроллит к искомому тексту, а не в комментарию (хотя тут уже дискуссионно что лучше). И браузер не скроллит кверху, если элемент весь помещается в экран.
Впрочем, штука не очень полезная.
Имею противоложное мнение. Возможно дело привычки. Я привык по этим вещам прямо ориентироваться. Где угодно. Хоть в редакторе, хоть в браузере. К примеру в vsCode я люблю file map-ы вместо скроллов. Очень упрощает многие вещи.
F3 Это, как раз, просто. Уже добавил.
Теперь по F3 фокус попадает в поисковую строку. А зачем? Или это такое поведение на Mac? В Linux/Win по F3 "find next". Т.е. скролл к следующему элементу. Вот кстати ещё 1 грабля на которую можно наступить — разные комбинации клавиш. Я думаю если сильно вникать то типичный UX состоит из огромного количества мелочей.
Ещё не хватает индикатора сколько всего найдено. Непонятно какое выделение из найденных текущее. Браузер имеет 2 стиля для этого.
Это нативный скролл с изменёнными стилями скроллбара.
Был неправ. Это и правда у вас такие стили (не стоит менять браузерные стили скролла без острой нужды, если вы не враг своему пользователю). Открыл этот же пост в обычном хабре — thumb не только намного шире (ура), но и намного большей высоты.
Хм. Пощёлкал понял ещё 1 бесячую вещь. Браузерный поиск умеет скроллить с текущей позиции экрана. Ваш ищет сначала всегда (либо с той позиции где были, если остановились).
Я думаю чем дольше копать тем больше мелочей выплывет. Слишком уж много UI тонкостей в современных UI.
Полагаю не помешает async поиск. Получится почти также быстро, но ещё и отзывчиво.
Для этого нужна многопоточность, которую достаточно сложно прикрутить. Тут разве что квантование может помочь. Но тогда придётся реактивную логику поменять на интерактивную.
К примеру в vsCode я люблю file map-ы вместо скроллов. Очень упрощает многие вещи.
Какие?
В Linux/Win по F3 "find next". Т.е. скролл к следующему элементу.
Проще перемещаться по Enter/Shift+Enter.
Непонятно какое выделение из найденных текущее. Браузер имеет 2 стиля для этого.
Агась. Чтобы это поддержать, нужно будет сделать компонент-обёртку надо всем приложением. Чтобы компонентам была доступна ручка "текущий найденный компонент". Туда же можно будет вынести и хоткеи с кастомными линейками. Но это как-нибудь потом.
не стоит менять браузерные стили скролла без острой нужды, если вы не враг своему пользователю
Нативные скроллбары выглядят препаршиво.
Хм. Пощёлкал понял ещё 1 бесячую вещь. Браузерный поиск умеет скроллить с текущей позиции экрана. Ваш ищет сначала всегда (либо с той позиции где были, если остановились).
Из-за чего, чтобы поискать сначала приходится сначала отскроллить на самый верху, кликнуть в свободное место и только тогда начинать поиск. Такое себе поведение.
Какие?
В первую очередь сложные манипуляции с текстом со множественными курсорами. По карте файла видно где и какого рода есть выделения. А так как она ещё и цветная то видно примерно структуру кода.
Нативные скроллбары выглядят препаршиво.
Это проблема ОС, не наша. Функциональность должна быть выше потребностей дизайна.
Проще перемещаться по Enter/Shift+Enter.
Это если вы никак не взаимодействуете со страницей. Т.е. как только Input теряет фокус Enter/Shift+Enter перестают быть полезными. Просто элементарно что-нибудь скопировать в буфер обмена. Или просто привычка выделять что читаешь (у меня к примеру есть такая дурацкая привычка).
Из-за чего, чтобы поискать сначала приходится сначала отскроллить на самый верху, кликнуть в свободное место и только тогда начинать поиск. Такое себе поведение.
Ну выбирая между: "искать всегда с нуля" и "когда всё таки надо искать с нуля — вначале кликнуть на стрелку "вверх"" я выберу второе. По моему опыту поиск с текущей позиции очень желаемое поведение. Если скажем вам в редакторе сделать такой поиск (всегда с нуля) как быстро вы пойдёте писать issue разработчикам редактора? Я минут через 5 :-D
Это проблема ОС, не наша. Функциональность должна быть выше потребностей дизайна.
Пока скроллбары отображаются внутри страницы — это проблема автора страницы. Неопрятный внешний вид вызовет отторжение у пользователя куда быстрее, чем минорные отличия в поведении. Кроме того, важный момент в том, чтобы обеспечить единый UX, что на мобилке, что на десктопе, а на мобилках нативные скроллбары вообще невидимые. Тут же они оформлены аккуратной полосой, не бросающейся в глаза.
Т.е. как только Input теряет фокус Enter/Shift+Enter перестают быть полезными.
Жмёте F3 и оно снова в фокусе.
По моему опыту поиск с текущей позиции очень желаемое поведение.
Лично мне поиск с текущей позиции нужен примерно никогда.
а на мобилках нативные скроллбары вообще невидимые
Проблема мобилок в том что там нет мыши (т.к. скроллом пользоваться было бы неудобно) и малый размер экрана (дорогое пространство). Поэтому там другие паттерны управления (свайпы и прочие жесты одним или несколькими пальцами, лонгтапы и бог знает что ещё).
Жмёте F3 и оно снова в фокусе.
Т.е. F3 + Enter. И не дай бог вы проскроллили с прошлого раза. Это не учтётся.
Лично мне поиск с текущей позиции нужен примерно никогда.
У меня сложилось впечатление что вам вообще не нужен поиск. И скроллбар. И наверное многое другое. А страдать пользователям. Потому что программист решил что так будет лучше. Предпочтения отдельно взятого разработчика становятся выше того, как у пользователя обычно всё работает. То к чему он привык. Ну такое.
Мне кажется с таким подходом лучше заниматься backend разработкой. Без обид… Но ведь правда.
Неа, что ввели — то и ищется.
Забыл про эту штуку. Вне демки (в реальном применении) так точно нельзя. UTF8 слишком муторная вещь. Человек тупо может не найти слово в котором какая-нибудь Ё записана через 2 code point-а. С другими языками, полагаю, граблей ещё больше.
В общем я не хочу сильно критиковать демку. Демка на то и демка. Спасибо за неё. И за статью. Но по ней, хорошо видно, насколько это неблагодарная работа делать virt. scroll-ы. Насколько много велосипедов нужно переизобретать или просто игнорировать. Многие вещи кажутся очень простыми при первом приближении. Но по факту являются сложными.
Человек тупо может не найти слово в котором какая-нибудь Ё записана через 2 code point-а.
А если оно ещё и с опечаткой написано, то вообще туши свет..
Многие вещи кажутся очень простыми при первом приближении. Но по факту являются сложными.
Сложными они получаются при попытке повторить все нюансы натива. Особенно в свете разного нативного поведения на разных платформах. Если думать о потребностях пользователя всё становится куда проще.
А если оно ещё и с опечаткой написано, то вообще туши свет..
Шутки шутками, но кто-то тут писал что Mac многие годы самую обыкновенную Ё писал через 2 code-point-а. И это создавал массу сложностей людям. А в UTF куда больше проблем, чем только вариативность записи буквы. Там даже uppercase и lowercase проблемные. Нормализация must have.
Если думать о потребностях пользователя всё становится куда проще.
Ну вот ваша демка яркий пример того, что оно и даром такое не нужно. Тормоза стерпеть ещё можно, а многочисленные нарушения UX только тогда, когда по-другому ну никак.
Причём обратите внимание, одно дело страдать с такими вот решениями тогда когда на странице пара тысяч комментариев. Но зачем все эти костыли и лишения на странице, которая и без того не тормозит? Скажем вот эта страница, на которой мы сейчас пишем. В итоге делать 2 UI? Один удобный для типовых сценариев и второй с virt-скроллингом для громоздких случаев?
Mac многие годы самую обыкновенную Ё писал через 2 code-point-а
А вот это уже должно решаться на уровне ОС, а не разбрасыванием костылей в каждом месте работы со строками.
Там даже uppercase и lowercase проблемные.
Поиск в демке идёт через приведение к нижнему регистру так-то.
Тормоза стерпеть ещё можно, а многочисленные нарушения UX только тогда, когда по-другому ну никак.
Вы хотите сказать, что ждать на мобилке по 20 секунд появления очередных 3 комментариев — это терпимый UX?
Но зачем все эти костыли и лишения на странице, которая и без того не тормозит? Скажем вот эта страница, на которой мы сейчас пишем. В итоге делать 2 UI?
Это вы, похоже, предлагаете сделать 2 UI: один для страниц с небольшим числом комментариев, а другой для страниц с большим числом комментариев. И где-то на 500 переключать с одного на другой.
Вы хотите сказать, что ждать на мобилке по 20 секунд появления очередных 3 комментариев — это терпимый UX?
Комментариев у хабра на мобилке можно сказать и нет вовсе. Выше я уже писал что там надо писать отдельный продуманный UI, адаптированный, малые экраны и touch-и. Там будет куда больше проблем чем только тормоза. Никаких чудес. Другая вселенная = другие UI
А вот это уже должно решаться на уровне ОС, а не разбрасыванием костылей в каждом месте работы со строками.
Что именно должно решаться на уровне ОС? Все проблемы UTF? :) Их там куда больше, чем эта вот одна. И ОС куда больше одной. И версий у ОС тоже. Не совсем понимаю с чем вы пытаетесь спорить. С тем что текст перед поиском необходимо нормализовывать (а в идеале ещё и стемить)? Ну если поиск не нужен, то можно и не делать.
Приведенный пример — вместо 8 элементов -> 3 элемента, вложенность 5 — выглядит цветочками.
Ягодки в реальном мире:
Битрикс — платные шаблоны Аспро, вложенность 32 и более, страница товара 5000 элементов.
Вордпресс — платные шаблоны, themeforest и т.д., если попалась вложенность меньше 24, то это просто удача)))
Тильда, не к ночи будэ помянута… — дичайшие простыни на любой чих.
Верстайте ручками!
Однако, при виртуализации, нам необходимо, чтобы каждый компонент умел делать разные дела…
— Узнать минимальные размеры без полного рендера.
— Частично отрендерить содержимое.
— Проверить соответствие поисковому запросу.
То есть объектная парадигма подходит для этого гораздо лучше, чем функциональная.
А что из этого нельзя сделать в мире React, например?
Автоматическая виртуализация рендеринга произвольной вёрстки