Здравствуйте, m2user, Вы писали:
M>Сегодня эта же дрянь (бесконечная прокрутка) вылезла на Озоне. M>При подготовке минимально воспроизводимого примера, обнаружил, что для возврата постраничности результатов поиска достаточно почистить Cookie и Local/Session Storage. M>Что это было
у озона часть разделов постраничная а часть (акционная чаще) с бесконечной прокруткой.
под угрозой они из-за "живого" фильтра. ставишь галку, пока подводишь мышку к следующему чекбоксу все страница перезагружается, все поля меняют свои места и ты кликаешь не туда куда хотел.
S>Ну у бесконечного скрола часто нет события "предыдущая страница" или "страница с номером 18", что помогает несколько упростить запросы к базе, например.
запросы-то такого же вида с параметрами типа page_num=xxx&items_per_page=yyy, а внутри уже LIMIT к базе и OFFSET. Что в случае пагинация, что в случае с фетчем – одинаково. Так что скорее всего фронт сам подсчитывает все. Ну может кто-то делает и фетчем на сервер, но с токенов. И даже в таком случае запросы к базе те же, просто оффсет и лимит на стороне бэка считается. А если и кэшируется что-то из базы, то все-равно одинаково кешируется.
короче, не вижу никаких упрощений запросов к базе. если знаешь точные примеры — поделись, любопытно.
vsb>Это удобней пользователю. Как раз постраничный вывод и нужен для уменьшения нагрузки на сервер. В идеальном мире с бесконечной производительностью ты всегда будешь получать полный список результатов поиска. Подгрузка результатов по мере скроллинга аппроксимирует этот идеальный мир.
DP>запросы-то такого же вида с параметрами типа page_num=xxx&items_per_page=yyy, а внутри уже LIMIT к базе и OFFSET. Что в случае пагинация, что в случае с фетчем – одинаково. Так что скорее всего фронт сам подсчитывает все. Ну может кто-то делает и фетчем на сервер, но с токенов. И даже в таком случае запросы к базе те же, просто оффсет и лимит на стороне бэка считается. А если и кэшируется что-то из базы, то все-равно одинаково кешируется.
DP>короче, не вижу никаких упрощений запросов к базе. если знаешь точные примеры — поделись, любопытно.
сам уже понял: мы просто тем самым убираем с бэка АПИшку и в-принципе возможность навигации к произвольной странице, тем самым разгрузив сервер
тем не менее, все же основная причина, думаю, высказана коллегами в соседних ветках: UX и всякие показатели удержания пользователей + показ им нужно информации + привычное потребление информации в виде бесконечной ленты
Здравствуйте, qqqqq, Вы писали:
M>>- VK: прокручиваешь wall posts группы на пару месяцев назад, а потом случайно попадаешь мышью на огромное поле сбоку и тебя перекидывает в начало Q>а если тыкнешь туда еще раз то перекидывает обратно где был
SK>у озона часть разделов постраничная а часть (акционная чаще) с бесконечной прокруткой.
хм, можешь привести ссылки на примеры разделов обоих видов?
В моем случае одномоментно во всех разделах пропали страницы.
Как уже писал, сброс куков и пр. локальных кешей исправил ситуацию.
Там где куки не сбрасывал до сих пор бесконечный скрол.
SK>под угрозой они из-за "живого" фильтра. ставишь галку, пока подводишь мышку к следующему чекбоксу все страница перезагружается, все поля меняют свои места и ты кликаешь не туда куда хотел.
Да, есть такое, но это мелкая непрятность, каких там ещё немало: неверные единицы измерения (мм/см), пропадающие фильтры и пр.
Здравствуйте, m2user, Вы писали:
SK>>у озона часть разделов постраничная а часть (акционная чаще) с бесконечной прокруткой. M>хм, можешь привести ссылки на примеры разделов обоих видов?
Затруднительно. я сразу так не припомню где именно, при каких условиях в озоне мне попадались ссылки в раздел с прокруткой. Там еще прикол в том, что другая ссылка на этот-же раздел показывает его постранично.
M>В моем случае одномоментно во всех разделах пропали страницы. M>Как уже писал, сброс куков и пр. локальных кешей исправил ситуацию. M>Там где куки не сбрасывал до сих пор бесконечный скрол.
Не, мне показывает то так, то эдак, без явной закономерности. если попадается прокрутка просто делаю шаг назад и перехожу еще раз.
SK>>под угрозой они из-за "живого" фильтра. ставишь галку, пока подводишь мышку к следующему чекбоксу все страница перезагружается, все поля меняют свои места и ты кликаешь не туда куда хотел. M>Да, есть такое, но это мелкая непрятность, каких там ещё немало: неверные единицы измерения (мм/см),
это продавцы криво заполняют карточки.
M>пропадающие фильтры и пр.
Здравствуйте, qqqqq, Вы писали:
Q>Ладно бы еще у скролинга был скролбар... но нет. Видимо предполагается что юзер обязан пальцем (если на тачдевайсе) или колесом мыши (если на десктопе) проскролить все-все-все, не пропустив ничего.
Членом он это должен делать, членом. Во всяком случае, я бы разработчиков такого и их руководство (и собственников) именно так заставил бы скроллить.
Здравствуйте, DiPaolo, Вы писали:
vsb>>Это удобней пользователю. Как раз постраничный вывод и нужен для уменьшения нагрузки на сервер. В идеальном мире с бесконечной производительностью ты всегда будешь получать полный список результатов поиска. Подгрузка результатов по мере скроллинга аппроксимирует этот идеальный мир.
DP>каким образом? что там, что там – одинаковые запросы на сервер и к базе. вот подробнее расписал http://rsdn.org/forum/web/8842263.1
Первый это запрос по конкретной странице, как было указано — с limit и offset. Проблема этого запроса в том, что он каждый раз отрабатывает заново. Я извлекаю 1 страницу — ну ок, 100 записей извлеки. Я запрашиваю 2 страницу, извлекли 200 записей, первые 100 пропустили, вторые 100 отдали. Я запрашиваю 1000 страницу, 100 000 записей извлекли, 99 900 пропустили, последние 100 отдали. Это квадратичный алгоритм. Он нормально работает, когда пользователю типично нужна первая, иногда вторая страница, но если пользователь часто скроллит далеко (а это реальный юзкейс во всяких инстаграммах, где юзеры могут скроллить часами), это неприменимо.
В принципе этот подход можно оптимизировать, если сильно нужно, добавить в базу поле "страница", пересчитывать его при удалении чего-то и тд. Это довольно муторно, но иногда нужно. Но когда условие может быть произвольным (к примеру результаты поиска сообщений конкретного пользователя, или вообще по произвольному условию), то этот подход оптимизировать нельзя никак.
Второй подход: сначала делаем запрос id > 0 and {condition} order by id limit 100. Возвращаем результат. Для следующей страницы клиент передаёт максимальный id предыдущей страницы и мы делаем запрос id > {prev_id} and {condition} order by id limit 100. Эти запросы уже всегда отрабатывают эффективно (конечно при условии наличия индексов). Минус этого подхода в том, что невозможно перейти с первой страницы на сотую. Т.е. сделать интерфейс с номерами страниц, как на типичном форуме, будет затруднительно. Можно только с текущей страницы перейди на первую, последнюю, предыдущую и следующую. Но если мы реализуем подгрузку результатов по мере скроллинга, то нам как раз и не нужно переходить на произвольную страницу, как раз именно переход на следующую страницу (или на предыдущую или возврат на последнюю) это типичный юз-кейс.
Здравствуйте, пффф, Вы писали:
П>Как ты это узнал?
Прикинь, мне потребовались годы чтобы это понять... ооо, а как эти прыжки вверх бесили-то до этого. Зато теперь я вконтактный спец!
Ну и ты тоже теперь знаешь великую тайну
