Comments 170
И о чем статья-то? Мне нужно отфильтровать данные, но это вообще невозможно и все ужасно! Поэтому я применяю реактивный подход, фильтрую и все здорово! Резюме — реактивное программирование, это спасение. Вопросы?
Вот что такое реактивный подход в однопоточном js программировании?

Статья о возможностях ОРП, о которых вы могли не знать. Похоже вы не дочитали до главы Парадигмы, где как раз объясняется, что такое Реактивное Программирование. В последующих главах уже объясняется как оно реализуется.

Если человек работающий с данными не знает что их можно фильтровать, то ему действительно будет очень полезна эта статья. А в остальном объектно реактивное программирование, это настолько же глупо звучит, как например объектно событийное программирование. Но если второе уже все понимают, то это не значит что более понятно было бы объяснять это как парадигму, максимум архитектура. Зачем все усложнять. Это всего-навсего несколько шаблонов проектирования, которые выполняют команды, которые теперь называют операторами, которые в свою очередь выполняю задачи, которые здесь называют просто функции.
И на мой взгляд если действительно понимать о чем идет речь, то за подобный объем можно четыре раза рассказать ИСЧЕРПЫВАЮЩЕ что это такое.

Что-то http://toys.hyoo.ru/ безбожно тормозит при скролинге. Какая-то анти-реклама $mol

А тут он и не нужен, собственно. На мобилках он и не показывается.

Надо тогда и на десктопе тоже его не показывать.


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

Если б ещё был безкостыльный способ его скрыть.


Там просто более 9000 товаров. Если вы захотели странного и умотали в самый конец списка, то получаете рендеринг всех товаров.

Нет, у меня повисла вкладка при попытке сдвинуть ползунок скролбара.

А зачем вообще вы пытаетесь выводить на одной странице 9000 товаров? Какова вероятность того, что пользователь промотает хотя бы до 1000? Вы всерьез можете представить ситуацию, как пользователь упорно сидит и мотает 5 минут страницу???

А думаете ему будет удобнее 50 раз кликнуть на "следующую страницу"?

Удобнее будет отфильтровать или перейти к нужной категории товара, представьте что амазон выведет миллионы своих товаров на страницу, как от этого толк вообще?
Пролистал сайт процентов на 40, памяти выделился гигабайт и не освобождается.

Ещё бы, вы запустите в консоли после этого $$('[my_toys_catalog_toy_card]').length и посмотрите сколько товаров на самом деле отображается на странице. В итоге тормозит всё: hover, открытие\закрытие панели товара, подсветка выбранного элемента.

Я не представляю такой ситуации, когда пользователь упорно проматывает тысячи товаров — не важно, в каком виде. Хоть скроллом, хоть с пагинацией, как угодно.

Очевидно, пользователь сперва применит какие-то фильтры, а потом, когда товаров останется ~несколько сотен, уже и будет просматривать.

Выходит, что:
1. в том случае, когда у вас 9к товаров, виртуальный скролл не нужен, потому что пользователь все равно не будет скроллить
2. а когда товаров несколько сотен — виртуальный скролл не нужен, потому что их можно подгрузить целиком

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

Ну и еще на десктопах меня лично виртуальный скролл всегда бесит — с ним, по очевидным причинам, не работает поиск

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


А браузерный поиск не нужен, если есть соответствующий фильтр по тексту.

> Эта фича позволяет быстро показать страницу, не парясь по поводу количества найденных фильтром товаров.

То есть вы сперва выдумали проблему (зачем-то решили показывать пользователю 9к товаров), а потом ее героически преодолели, не показывая их сразу, а показывая по-немногу.

> А браузерный поиск не нужен, если есть соответствующий фильтр по тексту.

Я когда захочу что-то найти на странице, то точно не стану искать какой-то там фильтр по тексту, а нажму ctrl+f. И когда поиск ничего не найдет — то в первую очередь подумаю, что на странице просто и нет соответствующих данных, а не то, что они не подгружены из-за виртуального скролла.
то в первую очередь подумаю, что на странице просто и нет соответствующих данных

Вот-вот. С точки зрения обычного пользователя все товары на странице есть, вот же они, можно пальцем в экран ткнуть и показать. Откуда пользователю знать что тут какая-то тормо-магия применена :)

Пользователь не слепой, чтобы не увидеть огромное поле поиска. Мало кто знает про комбинацию ctrl+f, а на мобилке нативный поиск ещё сложнее отыскать.

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

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

Ну-ну, я уже и забыл когда последний раз встречал в кастомных подсветку найденного :)

А я вот только неделю назад заметил, что на хабре есть поле поиска. Надо, оказывается, кликнуть на лупу. До этого я думал, что поиска нет кроме как на https://habrahabr.ru/search/

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

Это, разумеется, баг. Панель инструментов по умолчанию должна быть открыта. Залил патч.

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


И как паджинация поможет вам "искать по странице нативными средствами"? Или что вы предлагаете? Рендерить все 10000 товаров пару минут, чтобы нативный поиск работал?

И как паджинация поможет вам "искать по странице нативными средствами"?

facepalm.jpg. Элементарно, Ватсон. Пользователь видя постраничную навигацию понимает в каком диапазоне будет работать нативный поиск. Он понимает, что поиск затронет только текущую страницу. И пожелай он искать среди всех страниц, как раз пойдёт искать ваше "огромное поле поиска" (по сути от безысходности). Это будет очевидный интерфейс. И тормозить он тоже не будет.

Зачастую постраничная навигация находится внизу страницы, так что ничего пользователь не видит.

Давайте все-таки сравнивать с лучшими образцами, а не с худшими?


Если важно именно показать пользователю существование других страниц кроме первой — то постраничная навигация обязательно дублируется и сверху, и снизу.

Даже если постраничная навигация находится внизу страницы, пользователь ее увидит, дернув, например, за тот самый скроллбар, который у Вас заставляет браузер задуматься на пару минут. Я часто на незнакомых сайтах именно так и делаю — прокрутил страницу вниз и вижу либо что выведены все товары, тогда можно нажать ctrl+f и найти что-то конкретное, либо увидеть что еще 100500 страниц есть, тогда пытаемся использовать поиск сайта. более того, постраничный вывод тем и хорош, что там немного товаров и одна страница просматривается глазами за минуту максимум и редко занимает больше двух экранов, так что пользователь все равно с высокой вероятностью доскролит до пагинатора.
P.S.: http://toys.hyoo.ru — вывалился в ошибку сценария через минуту игры с фильтрами (браузер FireFox 53.0.3).
Вы, видимо, уменьшили количество элементов на странице, теперь их всего 1000, так что воспроизвести было немного сложнее, но все равно:
Похоже, исполняемый на этой странице сценарий занят или не отвечает. Вы можете остановить его сейчас, открыть сценарий в отладчике или позволить сценарию продолжить свою работу.

Сценарий: http://toys.hyoo.ru/-/web.js:675

При нажатии на подождать, сайт все равно не отвечает, ну а при остановке, все фильтры умирают)
не парясь по поводу количества найденных фильтром товаров

Ваш пример полное тому опровержение. Даже на сильном desktop-компьютере это работает очень медленно и отъедает очень много памяти.


А браузерный поиск не нужен, если есть соответствующий фильтр по тексту.

Не забудьте об этом пользователю написать в большой красной панели, чтобы он знал, что поиск ему не нужен. Пользователь то не в курсе. Он видит большую scroll-область, скроллит и видит на экране элементы. Ему и в голову не придёт, что их нет на самом деле. В случае какой-нибудь ужасной infinitive-ленты это хотя бы очевидно, т.к. и скролл меняет своё поведение по мере загрузки, и анимации loader-ов отображаются.

Вы кейсы не перемешивайте. Память съедается лишь при дорендеривании, что лучше, чем рендерить всё сразу.

Я зашёл на страницу, зыркаю на картинки и ищу чего бы мне купить. Игрушки всякие, ищу что-то интересно. Плавно кручу колесо и получаю все вышеописанные прелести. И да, когда я искал подарок на 8 марта я именно так и делал. Какие такие кейсы я перемешиваю?


Если я зашёл на вашу страницу и не стал скроллить вниз, то либо я нашёл что искал сразу (маловероятно, но бывает), либо я вообще оказался здесь зря. Это единственные use-case-ы которые представляют для вас интерес?

Подгружать следующую 1000 при пролистывании, скажем, 70% из этой 1000?
Вы точно даже представления не имеете о том, о чем пытались здесь написать.
А почему не сделать AJAX пажинацию, с сохранением страницы в url, и симуляции листания на мобильном устройстве: в конце прокручивания вниз, переходим на следующую страницу, и плавно прокручиваем вверх.

Поэкспериментировав с div'ми и эффектами, можно добиться того, что UX будет примерно как при бесконечном скролле, при этом не нужно хранить в несчастном дереве весь каталог.

Если постоянно прокручивать страницу вверх-вниз, то у пользователя быстро разовьётся морская болезнь. У меня есть одна интересная идея, которой ещё нигде не встречал — что-то типа двустороннего бесконечного скролла. Но руки пока не дошли до его реализации.

Это из-за того, что все карточки товаров — это ссылки, а нажатие колёсика на ссылке приводит к открытию ссылки в новой вкладке, но если вы сдвигаете мышь, то открытие отменяется.

Скорее всего вы умотали вниз, а потом перезагрузили страницу — он рендерит до того же места. Правда смещение скролла не восстанавливается. Пока что красивого решения этой проблемы не придумали. Есть костыль с проверкой изменений в дереве, но он тормозит. Ну и есть вариант вообще отказаться от фичи с восстановлением скролла при перезагрузке.

Да, точно, умотал вниз, потом перезагрузил, так как тормоза от перезагрузки обычно проходят. Но вообще у меня вроде быстрый десктоп. Может не стоит и пытаться рендерить слишком много, или сделать какое-то ограничение по-времени?
А надо ли рендерить то, что перед текущей страницей? Может просто поместить туда один пустой div с высотой в сколько-то страниц, и рендерить там только в случае если пользователь листает вверх.
У вас вроде все элементы одинаковые, зная кол-во элементов высоту можно вычислить.
Если немного разные, то можно примерно прикинуть среднее. На больших скроллах ошибка будет незаметна.
Если сильно разные, то можно делать анализ предположительно занимаемого места еще на сервере, и просто добавлять этот параметр в ответ сервера, наряду с названием, ценой и т.п. Ошибка на больших скроллах будет незаметна, а маленькие можно просто рендерить как есть.

Нет, тут все разные.


Это всё работает для отсекания снизу. Для отсекания сверху не годится иначе будут скачки.

Я уже отключил восстановление смещения скролла. Можете поиграться.

Прикольно! А как Вы писали библиотеку, которая, как раз, должна подобные проблему решать?

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

Подозреваю, что это из-за отсутствия поддержки пассивных обработчиков событий, из-за чего скроллинг выполняется не в отдельном потоке. Какая у вас версия Сафари и Оси? Лучше сразу писать в задачу: https://github.com/eigenmethod/mol/issues/225

Эх, промахнулся веткой(
Тормоза в сафари, версии: MacOS Sierra 10.12.5 (16F73), Safari 10.1.1 (12603.2.4).
В issue тоже отписался.
Треугольник, кстати, не тормозит. А так вообще замечал за сафари подобные тормоза, причём хром и фф не тормозили на тех местах.

Ваша реализация вирт. скролла безумно тормозит при попытке проскроллить на величину превышающую высоту экрана. Коль скоро вы его так всюду пиарите, дык доведите до ума. Этим сейчас в дэсктопном браузере просто невозможно пользоваться. $$('[my_toys_catalog_toy_card]').length === 3793 — WTF? Это вы называете виртуальным скроллом? Да сделать нормальный виртуальный скролл для элементов произвольной высоты задача не простая, у меня недели 2 ушло (правда там задача в стократ сложнее, чем просто список), но это же не повод в продакшн выдавать вот такую дичь.

Да не суть важно как вы это называете. Главное, что в таком виде, такому подходу место разве что на свалке. А вы его ещё и пиарите, эксцентричные бенчмарки рисуете, которые меряют каких-то никому не интересных попугаев, зато "из коробки". Но, дайте угадаю, это всё потому, что за вами нет гигантской корпорации вроде Google или Facebook-а :)

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

У каждого подхода есть преимущества и ограничения

Заинтриговали. А какие?


Скроллить больше, чем на высоту экрана за раз — не реалистичный сценарий.

Я машинально это сделал только открыв страницу. Так поступают многие. Да я даже эту страницу на хабре так скроллю. Так же в 100 крат быстрее.

Возможность динамически менять размеры элементов любым способом, например.


Боюсь люди, которые приходят в интернет-магазин поскроллить страницу, а не выбрать товар — не являются его целевой аудиторией.

Что мы имеем по факту:


  1. на малом количестве элементов ― выигрыш по производительностью ничтожен, но при этом ещё и сломан нативный поиск по странице (что, кстати, совершенно неочевидно для пользователя)
  2. на большом количестве элементов ― всё тупо дико тормозит и отжирает ОЗУ

Идём дальше, наш пользователь пришёл на страницу интернет магазина и хочет что-то купить. Следуя вашей логике, он либо покупает что-то сверху, либо закрывает страницу? А если не закрывает, но ищет (и скроллит разумеется), то пусть тогда у него всё тормозит? Я вот вспоминаю, как пользуюсь интернет-магазинами, дык я зачастую нахожу что-нибудь на 5-6 странице того же алиэкспресса, яндекс-маркета и десятка других магазинов. Может полчаса уйти прежде чем найду искомое.


Но наиболее странным мне тут кажется не то, что вы произвели на свет нечто странное, а то, что вы пытаетесь своё детище защитить тем, что мол пользователи не правильные, не правильно скроллят, не правильно браузером пользуются, про целевые аудитории рассуждаете. Какой ужас. Наверное теперь всякий раз, когда я буду натыкаться на жутко-тормозящее поделие в сети, я буду вспоминать вас, и вашу риторику про целевую аудиторию, про нереалистичные сценарии и прочее. На мой взгляд эта ваша презентация это Epic Fail.

О том и речь. 5-6 страница — это обычно порядка сотни-полутора товаров (и нет, рендерится эта сотня на хилых китайских тапках далеко не мгновенно). Если пользователь ничего не нашёл, то зачастую он бросает это дело — либо уходит, либо берётся за фильтры. Именно поэтому до рендеринга овер 9000 товаров никто не доходит. А тормозит в примере магазина при огромном числе отрендеренного из-за обновления каждого товара каждую секунду, добавленного опять же для примера, ибо реально товары не так часто обновляются.


Очень жаль, что вы не слышите о чём я говорю. Вот смотрите:


toy_cards() {
    return this.toys_sorted().map( toy => this.Toy_card( toy.id() ) )
}

Это — весь код рендеинга карточек. Эквивалентный код на Реакте или любом другом фреймворке будет безбожно тормозить.А ведь именно такого рода код пилится в 99% случаев, потому что "он проще" и "да у нас не будет тут много данных" и "на моём i7 всё и так быстро рендерится" и "прикручивание виртуального скролла — отдельная задача, на которую нет времени". Ленивый рендеринг позволяет работать быстро в 90% кейсов даже если данных много, а программист не запаривался над оптимизацией.

Эквивалентный код на Реакте или любом другом фреймворке будет безбожно тормозить

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


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


Т.е. резюмируя: ленивый рендеринг хорош тогда, когда его готовят с умом. А не это нечто.


это обычно порядка сотни-полутора товаров

Тут вам нужно пол статьи снести и большими красными буквами написать: моё решение имеет смысл если в вашем списке от 50 до 150 товаров. При больших масштабах он дико тормозит, при меньших просто не имеет смысла. Но даже при количестве 50-150 элементов вы получите неочевидный мёртвый поиск. Вива кривым ленивым решениям.


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

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


Ленивый рендеринг хорош, как оптимизация по умолчанию, которая в 90% случаев даёт хороший результат, не требуя дополнительных телодвижений. Если нужно оперативно работать со всеми 9000 элементами, то в этом случае нужно применять уже виртуальный скролл.

Вы придумали кривой велосипед и упорно пытаетесь всем доказать, что он не настолько кривой, не всегда кривой, иногда не кривой, и вообще если действовать строго по инструкции и жать "как надо", то даже ещё ничего. Смешно же :)


  1. Простое решение вашей проблемы: оставляете ленивый рендреринг, но лимитируете его неким N, за пределами которого начинается постраничная навигация. Тогда эти ваши, взятые с потолка, 90% пользователей останутся при ленивом рендеринге, а более дотошные юзера хотя бы смогут более-менее нормально пользоваться сайтом.
  2. Сделать что-то вроде как в VK комментарии. Когда постраничная навигация бегает сама, по мере скроллинга, заодно можно url менять. Думаю сделать это хорошо не тривиально, но и не так сложно, как сделать крутой вирт.скролл.

А так, вся эта ситуация, мне напоминает низкие дверные проёмы. В вашем случае по верхней части ещё свисает оголённый 220 вольт провод.

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

Кстати говоря, за всю свою практику, ни разу не сталкивался с подобными проблемами. Надо же хоть иногда мозг включать. По умолчанию всегда есть какая-нибудь навигация. Если же её нет, то у заказчика дотошно выясняются допустимые объёмы данных. Вот ни разу не было, чтобы я постфактум что-нибудь прикручивал. Может быть проблема где-то в другом месте?

В продуктовой разработке у вас нет ТЗ, только статистика, собираемая пост-фактум. Но даже в заказной всё не так радужно с ТЗ, к сожалению.

А что для того, чтобы догадаться сделать в списке пагинацию нужно ТЗ? :)

Вы не поверите, но чтобы предположить, что в списке может быть более 50 элементов — нужно ТЗ.

Нет, хороший разработчик должен делать такой предположение для любого списка, где более двух элементов (правило "раз — два — много")

Где же паджинация в списке тегов у поста и в списке ответов на мой комментарий?

А я и не говорил, что пагинация обязательна. Я говорил, что надо рассмотреть предположение.


В данном случае, пагинация оказалась не нужна.

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

"Особо никак" — это как? Вы бы стали добавлять им пагинацию, виртуализовать скролл или использовать ленивую загрузку для списка тэгов?

Я бы оставил дефолтный ленивый рендеринг, пока не потребовалось бы что-то большее.

То есть ваш фреймворк подписывается на событие скролла на абсолютно любом списке?


То есть любой сайт на $mol, где есть хоть один список, будет тормозить?


Кажется, ваш фреймворк еще хуже чем я думал до этого...

Нет, есть компонент $mol_scroll который реализует скроллящуюся область и провайдит информацию о видимой области в контекст. Все компоненты внутри могут получать эту информацию через контекст и использовать её при рендеринге.


Уже реализовано несколько раскладок:
$mol_list — для вертикальных списков
$mol_row — для горизонтальных с переносом
$mol_grid — для таблиц с фиксированной высотой строк.
$mol_float — плавающий за скроллингом блок


Также любой компонент может дать подсказку касательно своего минимального размера.

Тогда повторяю вопрос.


Будете ли вы использовать $mol_scroll для списка тэгов?

Гайз, может зря накинулись, может тормоза при скролле по одной из причин описанных в статье https://blogs.windows.com/msedgedev/2017/03/08/scrolling-on-the-web/?

У меря на планшете скроллинг не тормозит.
А ещё забавный момент с описаниями товаров и картинками, их тупо нет (картинки есть, но не уникальные в детальном просмотре), потому что если их добавить в данные но они и так уже 700кб, а будут несколько мегабайт (да там гзиповано, но практика показывает что есть куча ситуаций где это не работает + с описаниями будет и гзипованный контент весить очень много). А нет их, потому что будет тормозить загрузка, и автор не сможет показать что его технология полезна…

А ещё предлагаю посмотреть на потребление памяти страницы у меня хром на маке показывает 430 мегабайт.
И при скроллинге потребление памяти растёт, а потом не уменьшается (на 40% сожрал гигабайт памяти)…
image
Вот чуть-чуть поскроллил и несколько минут ничего не делал. Табы habrahabr.ru жрут 136 мегабайт.

Если вы скроллили только вниз, то с чего бы потреблению памяти уменьшаться?

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

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

P.S. Про картинки, например, в магазинах одежды их по 5 в среднем.

Ага, я-то пороха не нюхал :-)


Какая разница сколько у товара картинок?

В данном примере, добавляя по нескольку картинок к товарам (и не просто файл, а пути к картинкам), я думаю размер файла данных увеличится раза в 2 минимум. И на мобильном устройстве сидеть с пустым экраном и ждать пока по 3Г загрузиться не очень увлекательно. Плюс потребление памяти от страницы ещё возрастёт.

Путь к картинке лучше генерировать по шаблону из её идентификатора.

Многие фреймворки и CMS диктуют свои условия, например bitrix при аплоаде картинок пережимает и получается что-то вида "/upload/resize_cache/iblock/bcc/300_400_1/bcc730415057733bd87cfcdbae16d8bf.jpg". Или в рельсах: "/assets/next-15ade8f6ef88eea03d43a98fc6fbde8db53be8cbbfba66bc037a0a02d731e93f.png".
(примеры взял с реальных сайтов)
А есть ещё ситуации когда изображения отдаются с отдельного домена или сервера и тогда там ещё схему и хост приходиться добавлять к каждой картинке.

Или ваш фреймворк подходит только для специально написанного бэкенда?

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


Зачем к каждой картинке добавлять одну и ту же схему и хост? Их можно вынести в отдельную константу.

Проблема react не в VirtualDOM, а в его текущей реализации. Разработчики, естественно, об этом знают и по этой причине переделывают его см react fiber Смотреть за прогрессом можно здесь, а разницу в производительности на примере того же треугольника Серпинского здесь.
Следующая версия 16.0 уже использует его под капотом. Правда пока в режиме совместимости чтоб сильно не ломать.

Вообще-то я упоминаю fiber в главе про "треугольник серпинского на Реакте" и подчёркиваю, что это не решает проблему, а лишь размазывает её по кадрам приводя к визуальным артефактам. Можете сами попробовать открыть все реализации и подвигать мышью над кружочками. Файбер перестанет обновлять их содержимое, решив, что это "низкоприоритетное изменение", однако в зависимости от бизнес задачи низкоприоритетным может оказаться как-раз изменение размеров треугольника. Короче, fiber — адский костыль, который преподносят как манну небесную. Я пробовал реализовывать размазывание вычислений по кадрам (причём не только рендеринга, а всех вычислений), но из-за подобных визуальных артефактов отказался.

Вообще-то описываемого вами поведения не наблюдается. Пример с fiber — единственный, который у меня работает гладко, и я не вижу никаких артефактов. Ваш пример тормозит почти так же, как исходный.

Зная как они реализованы, не представляю, как оно может у вас не проявляться.

Хотя вообще да, присмотревшись, начал замечать глюки с наведением. Но всё равно версия с файбером у меня самая плавная.
У mol чаще FPS проседает и больше нагрузка на движок JS
image

P.S. на $mol_atom.actualize проседает

А реакт проваливается редко, но на долго. Подозреваю это от сборщика мусора.

У меня под хромом в версии с файбером вообще цифры не тикают почему-то.

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

> У вас слишком слабый комп

разогнанный i7 6700k
это что надо, чтобы оно тикало?
Уменьшал экран, менял масштаб, возюкал мышкой — иногда бывает раз-два тикнет и все. Забагованный этот ваш фибер, короче.

ЗЫ: открыл десять вкладок одновременно — так же 60фпс на каждой, но ничего не тикает. Явно не в железе проблема.
Кому-то сейчас покажется, что я что-то цитирую… ан нет, я копирую стиль в котором написана статья
и он ни капельки не ...

раздражает.
Таб хрома жрет 1гб+ оперативки если доскроллить до конца, кайф.
Вся реализация это грустная история о том, как инженер, не дружащий с UX, запилил решение, избавляющее юзера от проблем, которые на самом деле у него никогда не существовали. А само решение это просто ад для любого юзера, вследствие чего статья кажется нулевой с точки зрения полезности (если даже не вредной для неокрепших умов новичков).

Не напомните, что там у гугла на 100 странице? То, что вам дали скроллинг на 10000 товаров вовсе не означает, что нужно мотать его до конца. Так же как наличие 100 страниц в выдаче никого не заставляет идти до последней. Если пользователь не нашёл нужного в первой сотне товаров, то скорее всего он воспользуется фильтром и будет прав. Именно этот кейс мы поощряем, показывая ему панель с возможностью конкретизировать выборку.

С такой философией тупо лимитируйте выборку. В google зайдя на 100-страницу я не столкнусь в тем, что он отожрал 1 GiB памяти и всё страшно тормозит. Скажем когда я первый раз прикручивал SphinxSearch я лимитировал результаты 100-ей элементов. Вот что угодно можно на странице жать — она не зависнет. Даже если случайно куда-нибудь не туда ткнуть. В вашем случае достаточно просто ползунок дёрнуть. И дёрнут. Это обычный паттерн поведения пользователя ― бегло осмотреть что ему предложено. Сделайте на худой конец тогда уж "overflow-y: hidden", коли уж система столь уязвима.

overflow:hidden вообще запретит прокрутку. Это не решение. Если хотите — можете лимитировать выборку любым числом. Надеюсь не надо показывать как работать с функцией slice?

overflow:hidden вообще запретит прокрутку

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


Надеюсь не надо показывать как работать с функцией slice?

Дык я то умею. Мои интерфейсы не тормозят, ни у 90%, ни у 10%. И током не бьются тоже.

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

  1. Про отдельный тред вы пишете ввиду того, что заранее ожидаете таких тормозов, что это должно играть значимую роль? :)
  2. Прошлый раз я прицепил отдельный <div/>с нативным скролл-баром, отслеживая в нём onScroll.

Вы не сможете перерендерить весь экран целиком менее чем за 16мс на любом девайсе, когда пользователь дёргает скроллбар.


То есть вы предлагаете отключить нативный скролл, чтобы эмулировать его через нативный скролл? Ммм, хитро.

Разница с гуглом кардинальная — если в гугле я хочу (по каким-то причинам, вот хочу) попасть на 100 страницу, то я просто жму на 100 страницу. И все работает. То есть если функционал предоставлен — то нет проблем в его использовании. А что я делаю в вашем случае? Тереблю колесико 5 минут или пользуюсь скролом, который вешает вкладку? Какой смысл выводить потенциальные 9000 товаров, если пользователь все равно не сможет до этой условной девятой тысячи добраться? А если доберется — то у него все будет тормозить, виснуть, жрать память и т.д.? Получается, вы предоставили возможность домотать до 9000 товара, но тут же говорите, что «мотать не надо». А зачем даете потенциальную возможность, если «не надо»?

Потому, что мы не знаем сколько у пользователя памяти и как далеко он хочет домотать. Ну ограничим мы каким-то числом, а пользователю надо на 1 больше. В итоге он не получит своего, хотя разница в 1 погоды не сделает.

> Потому, что мы не знаем сколько у пользователя памяти и как далеко он хочет домотать.

Так он все равно не домотает, докуда хочет, зачем предоставлять возможность, которую нельзя использовать? Или вы полагаете, что кто-то правда будет 5 минут крутить?..

Вы знаете, это как на сайт повесить кнопку, при клике на которую она будет вешать вкладку. Можно, конечно. Но зачем?

А почему вы предполагаете, что он хочет пренепременно в самый конец огромного списка?

Так еще раз, если ему нельзя далеко скроллить, то зачем давать такую возможность? Уберите ее.
Одно дело, если бы оно работало — бог с ним, пусть, но оно ведь тормозит и виснет.

У пользователя есть возможность запустить 1000 программ, от чего комп тормозит и виснет. Какой лимит на одновременно запущенные программы вы бы установили?

У пользователя нет кнопки "запустить 1000 программ". Чтобы запустить 1000 программ — надо сделать 2000 кликов.


Вы же дали пользователю кнопку, на которую ему нельзя нажимать. Так не делается.

Программа может быть и одна. Бенчмарк какой-нибудь многопоточный.

Если пользователю нужно в конец — лучше предложить ему возможность поменять ориентацию сортировки.

Лучше. Но если вы дали возможность прокрутить в конец списка скролом — вы обязаны предусмотреть что пользователь этой возможностью воспользуется.

Если у него достаточно ресурсов для этого — пусть действует, какие проблемы?

Если вы считаете, что никто не будет смотреть 100ю страницу — просто не выводите ее. Нет нужды вешать браузер ради мифической "красоты" решения.

А есть смысл пользователю что-то запрещать, если ему очень надо?

Не стоит выдавать ограничение некоторых вымышленных сценариев за "ничего не работает". В том же ЯМаркете тоже можно накликать 100500 элементов. И что? А ничего, никто так далеко не листает.

В вашем случае не надо делать 100500 кликов, надо сделать один (!) клик

Не получится за 1 клик никак. Как минимум — надо хватануть и игнорируя тормоза довести курсор до самого низа.

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

Более того, судя по комментариям, все кроме vintage именно так и сделали, когда открыли эту злополучную демку. Стало быть мы тоже все вымышленные и не правильные. Не туда кликаем, не тем пользуемся, не правильно используем интернет.

Боюсь вы, в данном случае, не репрезентативны, так как ваша цель потестить реализацию, а не найти товар.

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

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

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

Решения восхищают когда они решают какие-то проблемы лучше других, придуманных ранее. А когда под решение придумывается проблема, это странно.
UFO landed and left these words here
Но автор пытается продать нам свое решение, а не просто теорию

Автор продаёт сферический ОРП, а примеры приводит на $mol_mem, так как остальные реализации ОРП поддерживают не все из описанных возможностей ОРП. У меня была мысль сделать некоторые примеры, например, на MobX. Но от этой идеи пришлось отказаться, чтобы не объяснять синтаксис каждой библиотеки, ибо время доклада не резиновое. И так пришлось урезать темы про логику работы ОРП-алгоритмов и про неидемпотентные реактивные задачи.


Посмотрите на примеры для библиотеки react-virtualized.

Вот вам виртуальный скролл на моле: http://mol.js.org/#demo=mol_grid_demo


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


Как можно говорить что vdom в react-е работает медленнее, чем моловское обновление DOM, если на примерах видно, что это не так?

В докладе я привожу в пример треугольник серпинского, там нет никакого ленивого рендеринга.

UFO landed and left these words here

Не стесняйтесь, покажите пример, который успевает.


Процент пользователей, умеющих в поиск по странице, катастрофически мал. И это без учёта его катастрофической ущербности.

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

Нет, никого (из сравшихся) это уже не интересует, т.к. нужно вникать, сравнивать с другими RP реализациями, а они, видимо, дальше мейнстримовых фреймворков в своем развитии пока не дошли…
Автору спасибо за статью, невольно позавидовал вашему легкому слогу. Сейчас работаю над статьей по другой RP-библиотеке, решил добавить в нее(статью) некоторые из ваших примеров, чтобы можно было параллельно сравнить подходы… Так что, полемика будет, но чуть позже.
Боюсь, поезд уже ушёл. Не бывает второго шанса создать первое впечатление)

vintage Вы как обычно воюете со стоячими ветряными мельницами. А они злобно минусуют вам карму. Вы слишком технологичны для того чтобы вас понимал среднестатистический хабражитель. У меня бекграунд флешовый поэтому я вас понимаю уже только потому что на флеше эта (или похожая на неё )тема была обжеванна много раз и много лет тому назад. Хотя кому это может показаться откровением. Но с флешем люди и не так извращались в своё время. Но это время прошло. Начинаем велосипедить по новой.

А к чему в итоге во флеше пришли? (Помимо того, что сам флеш заглох)

Дмитрий, да кто к чему. Однозначно заполнять компонент невидимыми в скроллируемой области данными не лучшее решение. Лично я дергал такое количество, чтобы всегда кэшировалось число записей равное числу записей видимой области умноженное на 3 (неважно поля или строки). Что касается лейаута. Я строил сразу весь визуальный объект по JSON структуре модели, а рендерил и отображал в соответствии с бизнес логикой активной сцены. Как всегда для меня сложность была с кастомизацией инпутов. Не знаю итог это для кого-то или нет.

Only those users with full accounts are able to leave comments. Log in, please.