Создаем кэшируемую пагинацию, которая не боится неожиданного добавления данных в БД
Если на вашем сайте присутствует большое количество контента, то для отображения пользователю его приходится так или иначе делить.
Все известные мне способы имеют недостатки и я попытался создать систему, которая сможет решить некоторые из них и при этом не будет слишком сложна для реализации.
Существующие методы
1. Пагинация (разделение на отдельные страницы)
Пагинация или разделение на отдельные страницы — достаточно старый способ разделения контента, который, в том числе используется на Хабре. Основным преимуществом является его универсальность и простота реализации как со стороны сервера так и клиентской части.
Код запроса данных из бд чаще всего ограничивается парой строк.
Тут и далее примеры на языке arangodb aql, я скрыл код сервера т.к там пока ничего интересного.
На стороне клиента мы запрашиваем и выводим получившийся результат, я использую vuejs с nuxtjs для примера, но то же самое можно проделать на любом другом стеке, все специфичные для vue моменты я буду подписывать.
Теперь у нас выводятся все посты на странице, но погодите, как пользователи будут переключаться между страницами? Добавим пару кнопок для перелистывания страниц.
Минусы данного способа
При достижении конца страницы пользователю нужно переключаться на следующую страницу вручную.
Не получится кешировать результаты, т.к посты находящиеся на странице 2, при добавлении новых, непременно сместятся на страницу 3, 4 и так далее, т.е одна и та же операция GET возвращает разные результаты в зависимости от количества постов.
Если в момент перелистывания добавятся новые посты, то мы повторно увидим просмотренные элементы на следующей странице и напротив, пропустим если будем листать в обратную сторону.
2. Бесконечный скроллинг
Этот способ решает первую проблему, теперь пользователю не нужно вручную переключаться между страницами.
Основная идея заключается в том, что мы получаем следующую страницу при достижении конца прошлой и добавляем новые элементы к существующим.
При таком подходе проблема №3 проявляются еще более явно, если раньше мы не могли увидеть 2 похожих элемента рядом, то теперь это станет обычной ситуацией, конечно можно воспользоваться грязным трюком и отфильтровывать элементы с совпадающим id прямо на клиенте, но что если добавится 40 новых элементов за раз? Мы потратим 3 запроса к серверу, чтобы достичь новых результатов, т.к прошлые сместятся на 2 страницы (при условии что на одной странице 20 элементов). Это не мой подход!
Как решают эту проблему люди из интернета:
Используют описанный мной выше подход, я не искал подтверждение, но я практически уверен в этом, т.к это самое простое решение которое может прийти на ум, его можно использовать для быстрого прототипирования или создания mvp.
Создают уникальный идентификатор при первом запросе, и сохраняют результаты запроса на сервере, а затем выдают порционно. Тут сразу напрашивается 2 минуса. Во-первых, это использование лишней памяти сервера для хранения результатов всех пользователей. Во-вторых, более сложная реализация, требующая и логики хранения результатов для каждого пользователя, и логики удаления устаревших запросов. Я уверен, что такие реализации существуют и возможно некоторым удалось решить проблему излишней памяти, но проще система от этого не стала, да и проблему кеширования это не решает, а лишь усугубляет ситуацию.
Возможны и другие более или менее изобретательные решения, но то что я хочу вам предложить я пока не встречал. В свое время мне бы очень помогла подобная статья, поэтому я и решил её создать. Думаю что людям с похожей задачей она окажется полезной!
Моя реализация
Основная идея в том, что нам придется немного изменить логику запроса к базе, при этом не потребуется добавлять новые сущности или добавлять новые параметры в запрос.
Обновляем код на сервере
Для начала решим проблему кеширования, для этого просто всё перевернем.
Теперь последняя страница станет страницей номер 0, а предпоследняя страница номером 1, слово страница (page) сюда уже не вписывается, т.к мы с детства привыкли что в книжках страницы идут с начала, поэтому используем более нейтральное слово offset (смещение).
Теперь сколько постов мы бы ни добавили, GET «/?offset=0» всегда будет возвращать один и тот же результат.
Получать первую страницу стало немного сложнее, поэтому совместим оба выше приведенных способа, для этого перейдем с уровня запроса к базе на уровень сервера (язык nodejs):
Чего мы этим добились:
Теперь перекрытия id после добавления новых элементов стали невозможны.
Запросы теперь статичны и легко поддаются кешированию, единственным плавающим по количеству элементов и их id остался запрос без параметра offset.
Наш код на клиенте теперь не работает(
Минусы моего способа:
Вопрос что делать при удалении все ещё открыт, это не частая операция, поэтому можно каждый раз полностью сбрасывать кэш, либо возвращать null вместо отсутствующего элемента, это неплохое решение, т.к. зачастую реального удаления с сервера не происходит, элемент лишь помечается как удаленный, если таких «null-зомби» станет много, то можно удалить все null-зомби из выдачи и сбросить кэш для всех запросов.
Если новый элемент оказывается не в начале после сортировки по выбранному полю (например по названию), то данный алгоритм не сработает. Поэтому подходит только сортировка по возрастающим или убывающим полям (например по дате или по id).
Обновляем код на клиенте
Заодно я покажу как сделать бесконечную прокрутку из пункта №2.
Теперь у нас есть полностью лишенная обозначенных недостатков реализация. Несомненно присутствуют моменты которые можно сделать лучше, я хотел показать сам подход, реализация может быть у каждого разной.
Бонус: Добавляем гибкую систему перехода по страницам
В данный момент мы можем перемещаться лишь на 1 страницу вперед или назад, добавим возможность перейти на любую страницу, элемент управления может выглядеть примерно так (в квадратных скобках текущая страница):
Основа метода для генерации пагинации взята из этого обсуждения: https://gist.github.com/kottenator/9d936eb3e4e3c3e02598#gistcomment-3238804 и скрещена с моим решением.
Показать продолжение бонуса
В начале вам нужно добавить этот вспомогательный метод внутрь тега
Теперь, при необходимости, можно перейти на нужную страницу.
Что такое пагинация страниц и как ее оптимизировать?
Пагинция – это ссылочный блок, с помощью которого на странице выводится часть информации из большого массива однотипных данных. В современных условиях пагинация приобрела форму, которой удобно пользоваться для навигации по страницам.
Работа с постраничной навигацией входит в список обязательных действий, осуществляемых SEO-специалистом. Однако стоит помнить фундаментальное правило поисковой оптимизации: страница должна быть релевантна ключевому запросу. Не нужно создавать бесчисленное множество дублей с идентичными заголовками (тег title и meta description). Для решения подобных проблем на помощь оптимизаторам приходит постраничная пагинация. О том, какой она должна быть в идеале, ходит много споров; этот вопрос поднимается практически на любом SEO-форуме или конференции. Попробуем разобраться в ситуации и внести ясность в эту проблему.
Что такое пагинация и ее разновидности
Существует множество методов реализации постраничной навигации с различным функционалом. Наиболее распространенными из них считаются:
Конечно, никто не запрещает применять более креативные идеи, например:
Это не противоречит сути пагинации, но выглядит уж слишком громоздко. Имеет смысл оставить просто стрелки: это удобнее и не отвлекает внимание пользователя от контента. Пример реализации:
Типы пагинации
Обратите внимание: отдельно взятая страница в подобных случаях имеет собственный URL:
Пагинация категорий. Когда на сайте множество категорий, подкатегорий, во время просмотра приходится неоднократно пролистывать страницу вниз. Решением проблемы стала их пагинация, представленная на примере ниже.
Листинг комментариев на блогах, тем, размещенных на форумах. При пагинации такого типа возникает одна сложность: контент, который сегодня находится на первой странице, завтра переместится на вторую, так как его место займут новые материалы. Чтобы не путаться, рекомендуется реализовать листинг по датам. Такие ссылки всегда будут вести на один и тот же контент, поскольку они будут содержать в своем адресе время публикации записи. В подобной ситуации можно использовать годы, месяцы, дни. При этом пагинация будет начинаться с главной, а далее – с максимальной цифры в URL-адресе:
Бесконечная прокрутка (infinite scroll). Данный тип пагинации является самым «продвинутым» среди современных способов разбиения на страницы. Реализовывается при помощи специального скрипта, который к текущей странице добавляет содержание следующей при прокрутке мышкой вниз.
Например, социальные сети широко используют infinite scroll, их интерфейс направлен на удержание внимания пользователей. Поэтому страница, грубо говоря, не имеет границ, ведь следующая выводится сразу, как только человек долистал до конца.
Обратите внимание! Статистика показывает, что большинство пользователей редко смотрят более трех страниц в выдаче. При этом они не всегда находят ту информацию, которая им нужна. Поэтому отличным вариантом станет расположение блока сортировки. Пример:
Определить, какой тип пагинации подходит именно для вашего ресурса, можно только при помощи анализа портрета целевого пользователя сайта. Для этого вычисляется поведение и основные потребности посетителей.
Пагинация для SEO: миф или реальность?
Действительно ли навигация страниц сайта полезна для SEO-продвижения? Смоделируем стандартную ситуацию, встречающуюся на большинстве проектов. На веб-ресурсе есть 60 страниц. Чтобы поисковому роботу добраться хотя бы до середины (в этом случае – страницы под номером 30), ему необходимо углубиться на несколько уровней, отыскать товар либо пост, перейти на следующий уровень. Конечно, бот обойдет и эту, и другие страницы, однако сроки индексации будут падать с последующим уровнем.
Вторым утверждением, отображающим бесценность внедрения нумерации, становится ограничение с ее помощью количества ссылок и поведенческие факторы. Ведь навигация по страницам – удобный и привычный для всех способ реализации длинных списков на ресурсе.
Советы и правила корректной оптимизации пагинации
Достойно реализовать и настроить листинг сайта несложно, достаточно следовать некоторым рекомендациям.
Метод 1. Использование noindex для удаления пейджинга из индекса поисковых систем.
После проверьте на отсутствие дублей URL 1-й страницы. Помните: на главную, к примеру “мой сайт.com/catalog”, нужно настроить “redirect 301” cо страниц “мой сайт.com/catalog/page=1”.
Такой метод прост и удобен в исполнении, но следует учитывать, что он исключает контент страниц из индекса. В случае большого количества товаров/статей/услуг время на их индексацию увеличивается (если не используется карта сайта).
Метод 2. «Показывать всё» и rel=“canonical” (основан на рекомендациях Google).
Метод 3. Применение Rel=“prev”/“next”.
Подразумевает создание цепочки страниц, начиная с самой первой и до последней.
На вторую нужно будет поместить предыдущую, следующую:
Далее действия аналогичны. Это долго и требует внимания. На заключительной странице цепочки необходимо указать лишь предыдущую:
Следует помнить, что Yandex не учитывает подобные атрибуты, а Google считает их вспомогательными, но не директивами.
Метод 4. AJAX, Javascript.
Для того чтобы отображать новые записи, подгружать товары из листинга или выводить все комментарии, при этом не используя традиционную постраничную навигацию, можно обратиться к Ajax-запросам. Они отрабатывают, когда страничка проматывается вниз. Основным плюсом такого метода является динамический доступ ко всему содержимому.
Ajax-подгрузка контента во время прокрутки страниц: этапы реализации
Фрагменты кода для JavaScript-события:
//запуск функции при прокрутке
$(«.text»).on(«scroll», scrolling);
function scrolling()<
/*отключение вызова функции прокрутки во избежание неоднократного вызова функции */
$(this).unbind(«scroll»);
//функция, реализующая следующие два этапа
loader();>>
//количество подгружаемых записей из БД
var count = 20;
//начиная с
var begin = 0;
function loader()<
//передача параметров
count: count,
begin: begin*count
>,
success:onAjaxSuccess
>);
function onAjaxSuccess(data)<
//добавление полученных данных
//в конец контейнера
$(«.wrapper»).append(data);
//возвращение вызова функции при прокрутке
$(«.text»).on(«scroll», scrolling);
>
//увеличение точки отсчета записей
begin++;
>
Посредством SQL и оператора LIMIT контент получают из БД, то есть выводят определенное число записей, хранящихся в разных блоках. Следующие действия – обращение в файле php к БД, демонстрация результата. В таком случае понадобится скрипт:
// указание параметров для подключения к MySQL
$host=’localhost’; // имя хоста
$database=’lazyloader’; // имя базы данных
$user=’root’; // имя пользователя
$pass=»; // пароль пользователя
//получение количества и позиции
$begin = ($_POST[«begin»])?$_POST[«begin»]:0;
$count = ($_POST[«count»])?$_POST[«count»]:12;
//формирование запроса к БД
$query = «SELECT * FROM база данных WHERE type=’тип’ LIMIT «.$begin.»,».$count.»»;
//выполнение запроса и получение результата
$result = mysql_query($query);
//формирование вывода данных, полученных из базы
while($row = mysql_fetch_array($result, MYSQL_ASSOC))<
echo «Английское название: «.$row[«name_en»].»»;
echo «Русское название: «.$row[«name_ru»].»»;
После этого следует проверить работоспособность.
Заключение
Неправильное использование пагинации ведет к возникновению ряда проблем для сайта. Некоторые из них:
Чаще всего лучшим решением станет применение двух методов: атрибута rel=”next/prev” (понятен для Google) и мета-тега robots=”noindex,follow” (подходит для Google, Яндекс). Это – “золотая середина” в работе с оптимизацией пагинации.
Пагинация страниц сайта — что это и как ее сделать
Когда мы читаем книгу, информация в ней подается постранично. Прочитывая одну страницу, всегда можно перевернуть, чтобы перейти к следующей, поставить закладку на самом важном или интересном месте, открыть сразу на трехсотой или четыреста двадцать шестой.
Это принцип не только «бумажных» книг — электронные работают аналогично, потому что подобный формат привычен и удобен всем людям.
Что же касается сайтов, то разделение на «фрагменты» данных проводиться далеко не всегда. Например, социальные сети — новости ВК, Фейсбука, Твиттера, — все они реализованы по принципу «бесконечной ленты». Крутить можно очень долго, особенно если у человека много «друзей» и подписок.
Принцип социальных сетей создан, чтобы «затягивать», но все другие сайты обязаны решать конкретную проблему заглянувшего к ним пользователя. Посетители приходят за информацией, за покупкой, за полезными данными, а если им приходится неизвестно сколько «крутить» сайт для обнаружения того, что нужно, — это плохо.
Причем, «плохо» не только с точки зрения самих посетителей, но и по «мнению» поисковых систем. Именно поэтому рекомендуется в любой проект, кроме социальных сетей, сделать пагинацию.
Что такое пагинация
Пагинация (пейджинг или постраничная навигация) — это разделение данных на страницы. На каждом сайте она может распределяться по своему принципу, среди примеров пагинации:
Даже поиск Google разделяется на страницы, хотя теоретически он «бесконечный», по некоторым запросам исчерпать список результатов практически невозможно. Тем не менее, система разделяет результаты постранично, чтобы обеспечить комфорт пользователю и более простую ориентировку в результатах.
Можно даже запомнить «ага, я нашел то, что мне лучше всего подошло, на пятой странице Google». Яндекс работает полностью аналогично, у него тоже есть пагинация результатов.
Для чего нужна пагинация
Самый очевидный ответ: для удобства посетителей, чтобы им не пришлось пролистывать «бесконечную ленту» и ориентироваться в слишком большом веб-ресурсе, когда нужно отыскать что-то конкретное. Однако есть и другие функции:
Последний фактор автоматически означает, что сайт с наличием на нем пагинации будет получать значительно больше SEO-«баллов», чем даже более технически «продвинутый», но без этой возможности. Нет смысла закупать дорогие ссылки, продвигать ресурс по ключевым словам и проводить другую работу по продвижению SEO-методами, если присутствует такая важная ошибка, как отсутствие пагинации.
Какая бывает пагинация
Существует несколько основных видов пагинации. Выбирать какой-либо из них можно, основываясь на структуре и предназначении сайта. У каждого типа есть собственные нюансы, которые необходимо будет учитывать в проработке веб-ресурса.
Пагинация с номерами страниц
Наиболее распространенный вид пагинации, просто разделяется даже теоретически «бесконечная» лента на определенные «куски», каждый со своей ссылкой и своим номером. Поисковые системы используют такой подход. Несколько требований к такому решению:
Такая пагинация достаточно универсальна, подходит под большинство видов сайтов.
Пагинация «Показать еще»
Некоторые вебмастера считают, что пользователи привыкли к бесконечной ленте в соцсетях, а значит, нужно давать им похожий интерфейс и на сайте с пагинацией. Пойдет такой вариант в таких случаях:
Достаточно распространенный метод пагинации для интернет-магазинов, поэтому его стоит иметь в виду. Он дает неплохую конверсию в сегменте одежды, интерьерных товаров, косметики.
Пагинация «бесконечный скролл»
Это тоже способ пагинации, который используется на сайтах с развлекательным контентом. Примером может быть известный портал Adme, который позволяет «крутить, сколько хочешь». Кажется, что здесь вообще нет пагинации, но она есть, выполняет такие функции:
Цель такой пагинации — имитация социальных сетей. Тот же Adme заставляет людей «зависнуть» на несколько часов, каждая новость создается специально, чтобы «зазывать» посетителей и не «отпускать». Это улучшает поведенческие факторы, но нужно понимать, что для чисто коммерческих проектов (интернет-магазинов) пагинация такого типа не подходит.
Алфавитная пагинация
«Честный» способ разделить статьи. Очень популярен такой подход на сайтах с рецептами. Пользователь просто нажимает на соответствующую букву алфавита, которая является гиперссылкой, и попадает в нужный ему раздел, где пролистывает до нужного подраздела — например, конкретного блюда. Довольно удобный вариант также для товаров и услуг.
Смешанная пагинация
Используется довольно часто: разделение на цифры и буквы, бесконечная прокрутка, но с возможностью зайти в определенный раздел. Существует мнение, что такой способ пагинации существенно улучшает юзабилити.
Проблемы пагинации
Оптимизация для поисковых систем касается не только ключевых слов и мета-тегов. Пагинация — один из важнейших параметров, если не соблюдать требования, то ни Google, ни Яндекс никогда не проранжируют сайт достаточно высоко, чтобы выйти хотя бы в ТОП-10 по ключевым запросам.
Поэтому желательно знать основные ошибки.
Одинаковые страницы (дубли)
Откуда берется ошибка: чаще всего «техническая», например, вы загрузили товар, потом обновили его характеристики. В идеале должна сохраниться новая версия, но некоторые движки делают копию «на всякий случай», причем, эта копия автоматически не удаляется.
В чем проблема: Google и Яндекс работают с помощью роботов и людей. Сначала роботы сканируют все имеющиеся страницы сайта на предмет ключевых слов, запросов, а потом эти результаты предлагаются специальным людям – асессорам. И машина, и человек может неправильно проиндексировать страницу, показывать неактуальную информацию вместо нужной копии.
Как исправить: существуют специальные сервисы — Netpeak Spider или менее известный Xenu, которые умеют проверять сайт на наличие повторяющихся страниц. Обе программы эффективно помогают справиться с ошибочными страницами.
Также можно воспользоваться сервисом Яндекс.Вебмастер, чтобы «выкинуть» из поиска те страницы, которым сервис ставит «неуд» и сообщает, что страница «недостаточно качественная». Потом можно будет их добавить, если информация обновится и будет соответствовать критериям качества.
Слишком много позиций
Откуда берется ошибка: характерна для интернет-магазинов, особенно крупных, с большим выбором различных товаров.
В чем проблема: Поиски просто не могут все проиндексировать, поэтому в «видимость» Google или Яндекс попадает только небольшая часть товаров, а если пагинация плохо настроена, то попадет что-нибудь старое, почти наверняка уже неактуальное для покупателей, потому что принцип «возраста» страницы все равно остается базовым для роботов.
Как исправить: в разделе Индексирования Яндекс.Вебмастера посмотреть, какие страницы находятся в поиске. Должно быть больше 90% в поиске, в противном случае необходимо редактировать пагинацию и вручную «указывать» поисковым системам на наличие товаров. Советуют сделать адрес страницы релевантным, например, не просто номер, а название: «iphon12max» или добавить специфические теги.
Универсальные способы для улучшения пагинации
Вопрос правильной пагинации — это не только комфорт пользователя, но и SEO-оптимизация. Специалисты в этой области спорят о том, как лучше всего оптимизировать сайт, чтобы было не только приятно пользоваться, но и «оценили по достоинству» роботы поисковых систем. Есть несколько достаточно надежных методов:
Можно установить в качестве «канонической» саму себя для каждой из страниц пагинации. Метод можно отнести к «наименьшему вмешательству», тем не менее, он способен улучшить ранжирование.
Некоторые из этих приемов до сих пор работают очень хорошо, хотя каждый из них был «придуман» несколько лет назад. Специалисты советуют пробовать, оценивать показатели, постоянно отслеживать позиции страниц в рейтингах, чтобы убедиться в эффективности указанных приемов.
Дополнительные правила пагинации
Есть еще несколько советов для уникализации контента и улучшения SEO-параметров пагинации:
Все эти характеристики не просто улучшают функционал, они также валидны для повышения сайта с «точки зрения» Google и Yandex.
Советы предлагаются не только для интернет-магазинов, хотя именно продвижение коммерческих страниц представляет особенную сложность для любого SEO-специалиста. Эти же принципы сохраняются для новостных, развлекательных и других сайтов.
Автоматизация пагинации
Некоторые современные системы создания контента предлагают автоматизировать функционал пагинации. Рекомендации для упрощения задачи:
Заключение
Совершенно необязательно вручную работать с каждой страницей, это и невозможно, если идет речь о крупном ресурсе с сотней или тысячей подразделов. Оптимальный способ автоматизации согласовывается между SEO-специалистами и программистами, отвечающими за функциональность веб-ресурса.
Мега-Учебник Flask, Часть 9: Пагинация
Это девятая статья в серии, где я описываю свой опыт написания веб-приложения на Python с использованием микрофреймворка Flask.
Цель данного руководства — разработать довольно функциональное приложение-микроблог, которое я за полным отсутствием оригинальности решил назвать microblog.
Краткое повторение
В предыдущей статье мы внесли все необходимые изменения в базу данных, для поддержки парадигмы «подписчики», в которой пользователи могут отслеживать посты других пользователей.
Сегодня мы, опираясь на то, что мы сделали в прошлый раз, доведем наше приложение до ума, чтобы оно принимало и доставляло настоящий контент для наших пользователей. Сегодня мы попрощаемся с последним из наших фейковых объектов!
Представление сообщений в блоге
Давайте начнем с чего-то простого. Домашняя страница должна иметь пользовательскую форму для новых постов.
Сначала мы определим объект формы с одним полем (файл app/forms.py) :
Далее, мы добавим форму в шаблоны (файл app/templates/index.html) :
Ничего сверхъестественного, как вы можете заметить. Мы просто добавляем еще одну форму, так же как мы делали раньше.
И напоследок функция представления, которая связывает все вместе (файл app/views.py) :
Давайте рассмотрим изменения которые мы сделали в этой функции, шаг за шагом:
И напоследок, перед тем как мы продолжим. Обратите внимание, что перед записью нового поста в базу мы делаем это:
Мы можем с легкостью пропустить этот редирект и перейти к рендерингу. Возможно это даже будет эффективней. Потому что все что делает этот редирект, на самом деле, это возвращает нас в эту же самую функцию.
Итак, почему редирект? Рассмотрим что происходит, когда пользователь пишет пост в блог, публикует его и жмет кнопку «Обновить». Что делает команда «Обновить»? Браузер повторно отправляет предыдущий запрос.
Без редиректа, последний был POST-запрос, который отправил форму, поэтому действие «Обновить» повторно пошлет этот запрос, в результате чего мы получим второй пост, идентичный первому. Это плохо.
Но с редиректом мы заставим браузер выдает еще один запрос после отправки формы. Это простой GET-запрос, и теперь кнопка «Обновить» будет просто еще раз загружать страницу, вместо повторной отсылки формы.
Этот простой трюк позволяет избежать вставки дубликатов сообщения, если пользователь случайно обновляет страницу, после публикации поста.
Отображение сообщений в блоге
Переходим к самому интересному. Мы собираемся вытащить из базы посты и отобразить их.
Если вы помните, несколько статей назад, мы сделали пару фейковых постов и мы показывали их на нашей главной странице долгое время. Эти фейковые объекты были созданы явным образом в функции представления в виде списка Python:
Но в последней статье мы создали запрос, которых позволяет на получить все сообщения от людей на которых подписан пользователь, так что мы можем просто заменить вышеуказанные строки (файл app/views.py) :
Теперь, когда вы запустите приложение, вы увидите посты из базы данных!
Метод followed_post класса User возвращает объект query sqlalchemy который сконфигурирован чтобы вытащить интересущие нас сообщения. Вызвав метод all() на этом объекте мы получим все посты в виде листа, так что в конечном счете мы будем работать с привычной нам структурой. Они так похожи, что шаблон ничего не заметит.
Сейчас вы можете поиграть с нашим приложением. Не стесняйтесь. Вы можете создать несколько пользователей, подписать их на других пользователей, и, наконец, опубликовать несколько сообщений, чтобы видеть как каждый пользователь видит свою ленту.
Пагинация
Наше приложение выглядит лучше чем когда-либо, но есть проблема. Мы показывает все сообщения на домашней странице. Что случится, если пользователь окажется подписан на несколько тысяч человек? Или миллион? Как вы можете представить, выборка и обработка такого большого списка будет крайне неэффективна.
Вместо этого, мы будем показывать потенциально большое количество постов разбив на страницы.
Flask-SQLAlchemy поставляется с очень хорошей поддержкой пагинации. Если, например, мы хотим получить первые три поста от отслеживаемых пользователей, мы можем сделать так:
Метод paginate возвращает объект Pagination. Члены этого объекта содержат список элементов запрошеной страницы. В объекте Pagination есть и другие полезные вещи, но их мы рассмотрим чуть позже.
Давайте подумаем, как мы можем реализовать пагинацию в нашей функции представления index(). Мы можем начать с добавления элемента конфигурации нашего приложения, который определяет сколько элементов на странице мы будем показывать.
Это хорошая идея, хранить глобальные настройки приложения, которые могут влиять на поведение, в одном месте.
В финальном приложении мы, конечно, будем использовать число больше 3, но для тестирования удобней работать с небольшим количеством.
Далее, давайте решим сейчас как будут выглядеть URL с запросом страницы. Мы видели раньше что Flask позволяет принимать аргументы в маршрутах, так что мы можем добавить суффикс, который укажет на нужную страницу:
Такой формат URL может быть легко реализован с помощью дополнительного маршрута в нашем представлении (файл app/views.py) :
Наш новый маршрут дергает аргумент с номером страницы и объявляет его как целое число. Нам также нужно добавить этот аргумент в функцию index() и выставить значение по уполчанию, потому что два из трех маршрутов не используют этот аргумент, и для них он будет использоваться со значением по умолчанию.
Обратите внимание, как легко проходят эти изменения, и как мало изменяется код. Мы пытаемся писать каждую часть приложения, не пытаясь предполагать как работают другие части, что позволяет нам строить модульные и надежные приложения, которые легко тестировать.
Сейчас вы можете испытать пагинацию, вводя URL с разными номерами строк в адресную строку браузера. Убедитесь что доступно более трех постов, которые вы видите на странице.
Навигация по страницам
Теперь нам нужно добавить ссылки с помощью которых пользователь сможет перемещаться к следующей/предыдущей странице, и к счастью для нас Flask-SQLAlchemy сделает большую часть работы.
Мы собираемся начать внеся небольшие изменения в функцию представления. В нашей текущей версии мы используем пагинацию следующим образом:
Делая это, мы только сохраняем элементы объекта Pagination, возвращаемого методом paginate. Но этот объект предоставляет несколько очень полезных возможностей, так что мы будем хранить весь объект целиком (файл app/views.py) :
Чтобы копменсировать это изменение, мы должны изменить шаблон (файл app/templates/index.html) :
Что нам дает объект Paginate в шаблоне. Вот методы объекта, которые мы будем использовать:
С их помощью мы можем сделать следующее (файл app/templates/index.html) :
Теперь у нас есть две ссылки. Вначале мы покажем ссылку «Newer posts», которая отправит нас к предыдущей странице, к новым постам. С другой стороны «Older posts» отправит нас на следующую страницу, к более старым постам.
Но, когда мы находимся на первой странице, ссылка на предыдущую страницу нам не нужна. Такой случай легко отследить по методу posts.has_prev, который вернет False. В этом случае мы показываем текст ссылки, но без самой ссылки. Ссылка не следующую страницу обрабатывается таким же образом.
Реализация подшаблона Post
Ранее, в статье, в которой мы добавляли аватар, мы определим подшаблон с HTML кодом рендеринга одиночного поста. Мы сделали этот шаблон, чтобы избавиться от дублирования кода, если захотим рендерить посты на разных страницах.
Настало время реализации этого подшаблона на главной странице Это будет так же просто, как и большинство вещей, которые мы делаем сегодня (файл app/templates/index.html) :
Удивительно, да? Мы просто заменили старый код рендеринга на include нашего шаблона. Таким образом мы получим более хорошую версию рендеринга, с аватаром пользователя.
Вот скриншот главной страницы в текущем состоянии:
Страница с профилем пользователя
Сейчас мы закончили с главной страницей. Мы также включили сообщения в профиле пользователя, но не все, а только владельца профиля. Чтобы быть последовательными мы должны изменить страницу профиля, чтобы он соответствовал главной странице.
Изменения аналогичны тем, которые мы сделали на главной странице. Вот краткий список того, что нам нужно сделать:
Это обновления функции представления (файл app/views.py) :
Обратите внимание, что эта функция уже имеет аргумент (никнейм пользователя), поэтому мы добавим номер страницы как второй аргумент.
Изменения в шаблоне тоже довольно просты (файл app/templates/user.html) :
Заключительные слова
Ниже я выкладываю обновленную версию приложения microblog во всеми изменениями, сделанными в этой статье.
Как всегда, базы данных нет, вы должны создать ее самостоятельно. Если вы следите за этой серией статей, вы знаете как это делать. Если же нет, то вернитесь к статье о базе данных, чтобы узнать.
Как всегда, я благодарю за то что следите за мной. Я надеюсь увидеть вас в следующей статье.