Pull to refresh

Comments 19

Что то у меня ваш первый пример не работает, а разве не проще было просто сделать коллбек для скролла, и проверять положения каждого блока с помощью getBoundingClientRect ?

UPD: работает, только надо перейти на codepen, во фрейме почему то не хочет, но все равно работает через раз, может спокойно перескролить некоторые секции в меню

Ваше решение менее производительное, так как вызывает ненужные forced layout\reflow

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

Как только у вас появятся сложный layout, который действительно будет долго пересчитывать, разница станет очевидной.

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

Тут вы правы, данное апи не покрывает всех кейсов.

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

Как только у вас появятся сложный layout, который действительно будет долго пересчитывать, разница станет очевидной.

Ну это уже проблема самого layout'a, не нужно громоздить миллионы DOM элементов на странице.

но разве просчет всех элементов, от положения, до их размеров, не идет перед рендерингом страницы

Это правда
А значит я вытягиваю данные уже просчитанные

Это неправда. При изменении некоторых свойств DOM элементов или вызове некоторых методов происходит приостановка выполнения кода и forced reflow.

При изменении некоторых свойств DOM элементов или вызове некоторых методов происходит приостановка выполнения кода и forced reflow.

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

Чтение некоторых свойств тоже вызывает forced reflow. Как пример scrollTop.

Надо бы почитать, не думал что get может тоже вызвать forced reflow, вроде уже сижу на ваниле более 10 лет, думал что уже знаю практически все, но временами находиться моменты, о которых даже не подозревал, век живи, век учись :)

UFO just landed and posted this here

Спасибо, хотя если честно, даже не до конца понимаю почему идет вызов forced reflow, понимаю при "elem.focus()", но что такого дает "elem.getBoundingClientRect()" ?

Вы в потоке, добавили пару елементов, ещё паре элементов изменили стили, но оно ещё не сделало рефлоу, т.к. ваш поток с логикой не закончился и рендер ещё не начался. И тут вы говорите: "а ну ка дай мне размеры и положение такого то блока". Для того, чтобы узнать это значение - нужно применить все ваши изменения. Потому что посчитано то, что было в предыдущем кадре, но не на текущий момент.

То есть вы мне хотите сказать, что браузер не проверяет ли были сделаны изменения, и при каждом вызове elem.getBoundingClientRect() делает forced reflow ?

Эмс. Где вы такое увидели вообще? Я как раз писал про изменения.

И да, браузер может дёрнуть рефлоу несколько раз за кадр (то есть в несколько раз больше, чем нужно) если вы изменяете-получаете-изменяете-получаете.

Создавать обработчик события на каждый из разделов и на каждую из картинок?
А если всё это добро еще и Single Page…
Очень быстро мы получим что-то медленное и протекающее.
Может лучше по-старинке? С одним обработчиком события прокрутки на всю страницу, который отлавливает позиции нужных элементов и работает без полифиллов на браузерах 20-летней давности.
А ссылки сделать на старых добрых якорях, чтобы работало вообще без скриптов.

Подход "каждый отдельный кусок страницы чего-то там отдельно мониторит и сам подстраивается" на самом деле прекрасно работает и не то, чтоб прям принципиально медленный относительно централизованного обработчика.
При одном важном условии: что это всё нормально написано, что обработчики сами по себе быстрые и не пытаются делать тяжелые действия просто потому, что кому-то было лень нормально код структурировать. Что всё обязательно сносится при сносе блоков, и не утекает память. И вот тут да, я с вами согласен в том плане, что децентрализованный подход даёт куда больше способов самому себе отстрелить ногу. Но это не минус подхода, а минус конкретной его кривой реализации.

Тут скорее вопрос в том, почему автор для решил для каждого элемента создавать свой инстанс Intersection Observer. Данное API позволяет отслеживать несколько элементов средствами одного инстанса.

"а там, где поддерживается, срабатывает не всегда корректно "

интересно в каком году вы живете?

По поводу имитации ленивой загрузки как мне кажется лучше наверно удалять скриптом атрибуты src после того как скрипт определит что ленивая загрузка не работает в браузере. И потом возвращать его когда нужно. В таком случае страница не останется без изображений при отключенном JavaScript у пользователя.


Для перехода между разделами сайта тоже есть естественное решение в виде якоря. Задаём разделу атрибут id (<section id="1">) и делаем ссылку на него(<a href="#1">Section 1</a>). И опять же навигация будет работать без JavaScript. А в случае если он включен клик на ссылку можно перехватывать и делать навигацию красиво.

Sign up to leave a comment.