PM
само понятие dirty, а точнее dirty bit гораздо старше ангуляра и большинства здесь присутсвующих =)
и это хорошо, значит мы с тобой не такие старые)))
Size: a a a
2020 December 09
МТ
Eugene Ilyin
В таком виде on:wheel|nonpassive|preventDefault={scroller} не работает сам скроллинг
Кроме того при возврате на страницу или монтировании window.scrollY может быть отличным от нуля изначально
Кроме того при возврате на страницу или монтировании window.scrollY может быть отличным от нуля изначально
У меня стоит nonpassive и preventDefault потому что я еще анимацию добавил у себя, так что можно их убрать
МТ
Марк Танащук
У меня стоит nonpassive и preventDefault потому что я еще анимацию добавил у себя, так что можно их убрать
Поправил репл
МТ
Плюс желательно дебаунсер добавить
EI
Не так. Вы опять не пишите bind:scrollY={Y} в переменную. В таком варианте onMount не потребуется.
А разве сокращение
Кроме того это не решает проблемы что prevScollY должен быть сохранен при монтировании.
Вы предлагаете при монтировании уйти от window в виде prevScrollY = scrollY
bind:scrollY не эквивалетно bind:scrollY={scrollY} ?Кроме того это не решает проблемы что prevScollY должен быть сохранен при монтировании.
Вы предлагаете при монтировании уйти от window в виде prevScrollY = scrollY
A
А, сокращение точно👌🏻
EI
Марк Танащук
Плюс желательно дебаунсер добавить
А зачем дебаунсер, если visible=true (много долго скролим вверх), то можно сколько угодно раз вызывать
true так true состояние не меняется, а значит и перерисовка не дергается.
visible=true внутри onScroll это же ничего не именит во время скроллинга.true так true состояние не меняется, а значит и перерисовка не дергается.
A
Ну так бинд и ловит координаты. Зачем их тащить из нативного window ?
EI
Ну так бинд и ловит координаты. Зачем их тащить из нативного window ?
Чтобы первый раз onMount сохранить текущий window.scrollY внутри prevScrollY для корретного расчета первой delta при первом событии.
A
А шо из переменной не берет при маунте?
МТ
Eugene Ilyin
А зачем дебаунсер, если visible=true (много долго скролим вверх), то можно сколько угодно раз вызывать
true так true состояние не меняется, а значит и перерисовка не дергается.
visible=true внутри onScroll это же ничего не именит во время скроллинга.true так true состояние не меняется, а значит и перерисовка не дергается.
https://svelte.dev/repl/33730646df8546d9a91e1f669c899b97?version=3.31.0
Если бы в вашем примере было исключительно visible = true, то да, но если проводятся проверки, то имеет смысл добавить дебаунсер. Та и вообще практика правильная.
Если бы в вашем примере было исключительно visible = true, то да, но если проводятся проверки, то имеет смысл добавить дебаунсер. Та и вообще практика правильная.
EI
Марк Танащук
Но on:wheel={scroller} это только на колесо, как вы и указали.
Но ведь надо еще на жесты, на клавиатуру
Разве on:scoll={scroll} не отрабатывает любое из этих событий вместе и подойдет тут лучше?
Но ведь надо еще на жесты, на клавиатуру
Разве on:scoll={scroll} не отрабатывает любое из этих событий вместе и подойдет тут лучше?
EI
Марк Танащук
https://svelte.dev/repl/33730646df8546d9a91e1f669c899b97?version=3.31.0
Если бы в вашем примере было исключительно visible = true, то да, но если проводятся проверки, то имеет смысл добавить дебаунсер. Та и вообще практика правильная.
Если бы в вашем примере было исключительно visible = true, то да, но если проводятся проверки, то имеет смысл добавить дебаунсер. Та и вообще практика правильная.
Но там всего один if чтобы посмотреть дельта больше или меньше нуля это быстрее и дешевсле чем тащить дебансер который внутри так же проверяет текущее время на наступление bounce, добавляет js кода в бандл и дополнительный вызов функции. Один if на предмет определения visible всяко дешевле и компактнее будет.
EI
Ведь в примере исключительно две строчки:
Тут нечего оптимизировать.
visible = scrollY === 0 || prevScrollY > scrollY;
prevScrollY = scrollY
Тут нечего оптимизировать.
МТ
Eugene Ilyin
Но там всего один if чтобы посмотреть дельта больше или меньше нуля это быстрее и дешевсле чем тащить дебансер который внутри так же проверяет текущее время на наступление bounce, добавляет js кода в бандл и дополнительный вызов функции. Один if на предмет определения visible всяко дешевле и компактнее будет.
А потом бац, станет 2 или 3 и внезапно просадка появится.
А дебаунсер делается в 2 строчки
А дебаунсер делается в 2 строчки
clearTimeout(timeout);
timeout = setTimeout(() => /* debounced */, 20);
МТ
Я уже не говорю о том, что например можно использовать gsap для более плавной анимации(например навигации) во время скролла и тогда дебаунсер обязателен (почти).
МТ
Eugene Ilyin
Ведь в примере исключительно две строчки:
Тут нечего оптимизировать.
visible = scrollY === 0 || prevScrollY > scrollY;
prevScrollY = scrollY
Тут нечего оптимизировать.
У меня есть знакомый любитель кастомных скроллов и он мне недавно показал как новенькие браузеры могут тригерить по 500 раз скролл в секунду :)
МТ
И вполне просто
EI
Марк Танащук
А потом бац, станет 2 или 3 и внезапно просадка появится.
А дебаунсер делается в 2 строчки
А дебаунсер делается в 2 строчки
clearTimeout(timeout);
timeout = setTimeout(() => /* debounced */, 20);
Нет моя логика в том, что это все очень дорогие функции и вызовы + раздувание продакшн бандла. Такие тяжелые системные вызовы никогда не будут быстрее быстрее двух строчек:
Сейчас этот код оптимален и debounce на него его замедлит.
visible = scrollY === 0 || prevScrollY > scrollY;
prevScrollY = scrollY
Сейчас этот код оптимален и debounce на него его замедлит.