Архитектура пагинации

Question

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

1. самые новые сообщения должны всегда отображаться на странице индекса
2. каждое сообщение должно всегда отображатьсяна той же странице, так что он будет доступен в будущем

Прежде чем я начал создавать функциональные возможности разбиения на страницы, я понял, что было бы не очень удобно, если бы я воспринимал index.php как page 1 и постоянно добавлять страницы с новым содержанием к ним.Кто хочет видеть один и тот же page 1 с одинаковым контентом каждый раз, когда они посещают ваш сайт?Никто не должен вручную переходить на новый контент каждый раз, когда они посещают ваш сайт.

Мое решение вышеуказанной проблемы состояло в том, чтобы всегда рассматривать index.php как самую последнюю страницу.Я полагал, что это полностью решило проблему, но я, очевидно, не продумал это до конца.Несмотря на то, что этот подход лучше, поскольку новейший контент и новейшая страница всегда отображаются на index.php, я понял вчера вечером, лежа в постели, что, если я всегда заполняю index.php до максимальной вместимости, скажем, 10 постов,тогда оставшаяся часть сообщений ($ postCount% 10) всегда будет отображаться на page 1, и, следовательно, все сообщения будут постоянно перемещаться вперед и назад на 9 позиций.Например, если бы было только 10 постов, все они показывались бы на page 1, но как только кто-то отправит 11-й пост, все посты, кроме самого старого или самого 1-го поста, появятся на page 2;Кроме того, если будут опубликованы дополнительные 9 сообщений, самые новые 10 будут отображаться на page 2, а самые старые 10 будут отображаться на page 1 as expected; but, again, as soon as somebody publishes the 21st post, then the newest 10 would show up on страница 3 , the next newest 10 would show up on страница 2 , and the oldest post would obviously show up on страница 1`.

Очевидное «решение» или «исправление» этой проблемы состояло бы в том, чтобы не заполнить index.php полностью 10 сообщениями, а вместо этого отобразить остаток на index.php.Но я надеюсь, что это очевидные причины, по которым я не хочу этого делать.

Кто-нибудь сталкивался с этой проблемой раньше? Как я могу спроектировать архитектуру так, чтобы index.php всегда была самой новой страницей с самым новым контентом, и все же посты всегда можно было найти на той же странице, не перемещаясь вообще?

Любая помощь или понимание будет с благодарностью!<3 </p>

Answer 1

Большой вопрос: вам действительно нужна «нумерация страниц»?

Недавно я принял немного другую схему нумерации страниц.Я перечисляю элементы на основе граничных условий : и идентификатора элемента, который существует за пределами следующей страницы.

Допустим, у вас есть страница, содержащая элементы 41, 39 35 и 34.На предыдущей странице будут 4 элемента, которые после 41 , а на следующей странице будут 4 элемента, которые до 34 .Таким образом, ссылки, которые вы получите в итоге:

• первая страница: /list?limit=4
• следующая страница: /list?before=34&limit=4
• предыдущая страница: /list?after=41&limit=4
• последняя страница: /list?after=0&limit=4

И в этом случае «следующая» страница »будет содержать элементы 33, 32, 30 и 29.... и вы можете использовать идентификаторы с этой страницы для вычисления новой навигации.

Основным недостатком является то, что у вас нигде нет "счетчика страниц". Но вместо этого вы получаете страницы, которые всегда будутсодержат ожидаемые элементы (если они не были удалены), возможность кэшировать содержимое и встроенную обработку для состояния «что делать, если такого элемента нет». В качестве незначительного бонуса вы также получаете немного лучшую производительность в SQLКроме того, из-за отсутствия необходимости использовать offset .

Я лично начал использовать этот подход при работе со структурами REST API.