Comments 25
UFO landed and left these words here
UFO landed and left these words here
Это всё усложняет. Нет проблемы получить размер элементов рендеря их где-то в скрытом блоке. Есть другие проблемы:
  1. Нужно еще дожидаться загрузки всех картинок (если их размер не известен заранее)
  2. При любом изменении размеров окна браузера нужно проводить все расчеты заново

А самое веселье начинается, когда речь идёт о таблицах в 300 тысяч строк, где чуть ли не произвольным образом расставлены col&rowspan-ы. Тут уже правда без изменения чего-либо в самом контенте даже чёрная магия не спасёт.

UFO landed and left these words here
Скажем у нас есть лента. Обычная лента – например как в Instagram. В ней есть картинки, комментарии, текст. Размер всего перечисленного не известен заранее.
Тут пользователь решает перевернуть свой iPad/перенести окно браузера на внешний монитор/ изменить размер окна. Всё ломается.
UFO landed and left these words here
самый обычный чат — размер (высота) любого сообщения неизвестны до рендеринга
UFO landed and left these words here
Дак мы как раз и боремся с тем чтобы их рендерить, вы вообще статью читали? Или вас просто эта проблема не ксонулась
UFO landed and left these words here
Восхитительная работа! Интересно, нет ли каких-то css-селекторов на сей счет, типа :target
Демо-пример явно недоработанный. Пока скроллим вниз — все нормально. Но если перейти в начало (нажать «Home» / перейти по якорю #) — то увидим лишь белый экран. И еще, при скролле вверх скроллбар дергается как ненормальный. Chrome 54.
Якорь — это уже «украшательства». Смысл трюка и без него понятен.

Скролл прыгает потому, блок с новостями имеет определённую высоту, он единственный, при скролле вниз блок сдвигается с позиции 1 на позицию 3. При скролле вверх сдвигается с позиции 3 на позицию 5. Т.к. ничего кроме блока нет, то и размер документа уменьшается (голубая линия), соответственно скролл прыгает.
Чтобы это исправить, нужно увеличивать ещё и высоту документа
image
Демка нацелена лишь на то, чтобы показать работу IntersectionObserer'а. Работает корректно только когда скроллинг происходит без якорей.
Нет смысла тратить время на доработку демо так как спецификация на IntersectionObserver и браузерная реализация могут поменяться.
При быстром скроллинге вверх удалось вылететь на белый экран в chrome 55
В статье всего лишь простенькая демка, которая работает только вниз, чтобы работало вверх, нужно дорабатывать алгоритм, но для демонстрации принципа в этом нет смысла

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



Хромиум начиная с 51 версии поддерживает, значит как минимум 60-70% посетителей уже могут оценить новый подход, фаерфокс с 52 версии, для остальных есть небольшой полифил. В crosswalk для мобильной разработки тоже уже доступен
Технология бесспорно полезная, но сама идея стара как мир. Как уже упоминалось выше можно рендерить контент порциями и просто считать высоту для принятия решения что нужно дорендерить/удалить.

По поводу доработки демки, тут проблема в том, что можно так скролльнуть что элемент не попадет в экран и событие не вызовется, с подсчетом высоты это решается легко, а вот с событиями — не все так просто.
Создается «listview». Подгружаться новые посты будут группами по 50 (можно меньше или больше)

Создается единственный IntersectionObserver. При создании новой группы из 50 элементов, на эту группу делаем io.observe(groupX)

После того как group1 исчезает из поле зрения, ее выгружаем, добавляем group3. Как только переходим на group3, выгружаем group2, загружаем group4 и т.д.

При резком скролле в самое начало срабатывает общее событие, среди всех entries мы ищем ту группу, которая получила видимость, показываем ее. При 10000 постов, у нас будет 200 групп, при наступлении нового события нужно всего лишь перебрать в цикле массив из 200 групп и понять какой из них в поле зрения. Это происходит почти мгновенно

Суть в том, что создается один единственный IntersectionObserver, который без потерь следить за множеством объектов, не нужно постоянно следить за скроллом и вычислять высоту, закладывать в архитектуру фиксированность размеров блоков или вычислять их после рендеринга
Прокрутил демо скроллом вниз, потом взялся за ползунок и потянул вверх — все сломалось, остался только белый экран.

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

Поведение скроллбара жестко зашито внутри браузера/оси и показывает физическое положение относительно высоты страницы. Он не рассчитан на бесконечные ленты, поэтому и вылезают такие косяки.

Scrollbar штука относительно простая. И никакой сложности им манипулировать нет. Я помнится поступал просто: размещал рядом с view-областью <div/> с width: 1px и программно регулируемой высотой. И scrollBar заиграл по моим правилам.

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

1 December 2010

Location

Россия

Employees

51–100 employees

Registered

18 April 2016