Pull to refresh

Comments 24

Решение проблемы бесконечной прокрутки — не делать бесконечную прокрутку.
Не всегда это возможно. Если у тебя лента твитов, сообщений и т.п.
Всегда возможно сделать при прокрутке вниз кнопку — Показать еще.
А вообще, хуже бесконечной прокрутки может быть только бесконечная прокрутка вверх, как например в чате в Фейсбуке (с точки зрения реализации).
Это тоже бесконечная прокрутка. При 10 нажатиях «показать еще» у тебя на странице столько областей видимости и биндингов будет, что начнутся тормоза. Проблема в том, чтобы удалять старые данные.
зачем на список твитов биндинги данных? они фактически не изменяются, и более эффективно не делать так, потому что это просто бессмысленно. да и вообще это очень часто не нужно, зря везде все так делать начали, зря зря зря.
В AngularJS разве можно иначе? Получили модель, одели ее на вьюшку. Байндинги — это просто следствие.
Буду знать, спасибо. Интересный подход, хоть и хак ангулара.
Кнопку показывать, количество лайков и ретвитов динамически менять. Можно, конечно, и без них, сделать костыль и через всплытие событий все разруливать и ng-repeat переписать, чтобы не создавала обособленные области видимости, но тем самым мы лишаем себя всех ангуляровских удобств, а это глупо
глупо бессмысленно тратить ресурсы. а организовывать трансялцию всех событий в реал тайме — безумно дорого, а не в реалтайме это несколько теряет смысл и так никто не делает.
На что биндинги? На кнопку показать еще?
Хотя бы и кнопку показывать
А зачем кнопку показывать? Почему ее просто не отрендрить в конце? Единственный биндинг — на клик по кнопке, чтобы на ее месте отобразить процесс загрузки, а потом и вовсе убрать
Имел в виду кнопки ретвитов и т.п. Плюс каждое выражение {{twitt.author}} {{twitt.title}} {{twitt.text}} вотчится в области видимости. В итоге, при большом списке цикл грязной проверки будет проверять тысячи элементов, что не быстро.
Зависит от цели. Если ваша цель показать как можно больше «записей», то тогда бесконечная прокрутка — просто подарок. Во всех отношениях.

А если у вас проблемы с выдачей большого количества «записей» — тогда да, приходится «затруднять» навигацию всякими кнопочками и линками.
Вы не поверите, есть такая штука, о ней мало людей знает, говорят ей пользовались наши мудрые предки. Называется постраничной выдачей, можете себе представить? И что делает ленту твитов такой уникальной, что ее по страницам нельзя распихать?
Угу, еще одна история о том, как web-страница хочет быть приложением, на этот раз — с некой своеобразной эмуляцией memory management. Проблема только в том, что действительно можно написать все так, что объекты DOM будут удаляться, но это не гарантирует того, что настоящая память тоже будет освобождена (да, это вопрос и к разработчикам browser-ов, но обязаны ли они были такое предусматривать?).

Например, у меня есть нетбук c гигабайтом оперативки и отключенным page file для тестов — на нем уронить firefox с ошибкой «недостаточно памяти» бесконечным скроллом — только так, достаточно страницы с «кумулятивным объемом» всего 60-70Мб (с картинками).

Я уже не говорю о том, что все эти бесконечные асинхронные загрузки, которые не отражаются в URL (а кто об этом беспокоится?) рушат сами базовые концепции web непонятно ради чего. Лет 10 назад получить от кого-нибудь ссылку на корень сайта с объяснениям «там надо еще нажать туда и туда...» было редкостью, сейчас все уже привыкли, что из адресной строки нет смысла копировать.
Думал об этом. Мне нравится идея из первой статьи где парень оперирует страницами. Можно и хеш в адресной строке менять при скролле, тогда и с ссылками проблем не будет.

Тут смысл не столько в экономии памяти (хотя и в этом тоже), сколько в уходе от лишних расчетов для того, чего не видно.
UFO just landed and posted this here
В первом случае это будет «брать из начала очереди и переставлять в конец»? Тогда это еще более адское вмешательство в разметку…

Best practice с hash в URL есть, кое-кто это использует, но это все равно ситуация из разряда «оторвать ногу, чтобы ее потом пришить». При том на сколько продуктивны все эти вещи и сколько ругательств от обычных пользователей это порождает — достоверно неизвестно. По моим многолетним ощущениям, best practice — это «если можно не использовать скрипты — не используй их».
UFO just landed and posted this here
По поводу последнего вопроса — я, на самом деле, жду, когда кто-нибудь из разработчиков browser-ов вспомнит про XLink вообще и конкретно — xlink:show=«embed», и большая часть ajax-костылей на JS перестанут иметь смысл, потому что все эти фокусы будут поддерживаться browser-ами нативно. :) Вон тот же JQuery mobile это в явном виде эмулирует…
А пока эти вещи приходится заменять чем-то, вот я и интересуюсь, что же еще придумали «от бедности».
Видимо пора новой технологии не основанной на DOM и html. С одной стороны веб приложения (и всякие single-page) вещь нужная с другой стороны, строя эти приложения по верх старых технологий получаем химеру.
Sign up to leave a comment.

Articles