Зробіть наступну дію невеликою
Припустімо, ілюстративний туристичний застосунок шукає offline maps у hiking з limit=3 і page=1. Читач відкриває повернені матеріали й вирішує, чи буде корисною наступна група. «Показати ще» має запитувати наступну сторінку того самого питання, а не непомітно обходити всі сторінки або змінювати запит зі старими результатами на екрані.
Візуальна підказка — елемент «Показати ще», який з’являється, коли відповідь дозволяє наступну сторінку. Поки дія очікує, вимикайте повторну активацію й залишайте вже показані матеріали доступними. Кожен успішний запит сторінки витрачає один кредит, включно з порожньою. Зупинившись до запиту наступної сторінки, читач уникає майбутнього запиту; вихід з екрана не гарантує скасування чи повернення за вже надісланий.
Зберігайте стан запиту разом
Залишайте q, subreddit, решту вибраних фільтрів і limit незмінними під час збільшення page. Якщо читач змінює фразу чи діапазон дат, почніть нову послідовність із page=1. Друга сторінка іншого запитання, додана до попереднього списку, спотворює історію читання, навіть коли обидва запити успішні.
Архів використовує порядок _doc. Це не порядок за хронологією, релевантністю чи оцінкою; min_score є фільтром, а не вказівкою сортування. Можна перевпорядкувати вже отримані записи для показу, але це не визначає глобально найновіші чи найкращі збіги. Повторні запити сторінок не мають гарантії сталого знімка даних.
Спирайтеся на відповідь, а не цикл пошуку порожньої сторінки
pagination.has_more ґрунтується на додатковому перевірочному записі там, де вікно запиту це дозволяє. Пропонуйте наступну дію лише за has_more=true й номера сторінки меншого за 100. Не продовжуйте запити до появи порожньої сторінки: сервіс уже надає сигнал продовження, а додаткові успішні запити коштують кредитів.
Читайте pagination.total разом із pagination.relation. eq означає точне число за правилами підрахунку цієї відповіді; gte — нижню межу, а не статистичну оцінку; unknown не надає надійного підсумку й може супроводжувати null. У гіпотетичній першій відповіді з трьома записами, total=4 і relation=gte можна написати, що вказано щонайменше чотири збіги. Не можна стверджувати, що їх рівно чотири.
Розпізнавайте обмежене вікно
Межі становлять 100 записів на запит і 100 сторінок. На сторінці 100 за limit=100 повна остання сторінка не залишає місця для додаткового перевірочного запису. Тож pagination.window_exhausted може бути true, коли has_more=false і relation=gte. False у has_more на цій межі не доводить відсутності подальших збігів в архіві.
Порожня сторінка після page=1 також не встановлює глобального підсумку; для такого випадку шлюз позначає total як unknown. Пояснюйте читачеві реальну межу, наприклад «Досягнуто межі цього вікна пошуку», а не «Усі обговорення завантажено». Звуження запиту допомагає організувати подальшу роботу, але не перетворює обмежені запити на вичерпний експорт.
Об’єднуйте обережно та залишайте можливість відновлення
Якщо справжній ідентифікатор запису є, застосунок може не показувати той самий запис двічі у власному накопиченому списку. Вибирайте правила ідентичності з фактично отриманих полів; не вигадуйте відсутній ID і не об’єднуйте різні записи лише через схожий текст. Локальне усунення дублікатів не доводить повноти решти списку.
Невдалий запит наступної сторінки має залишати попередні записи й запитання незмінними, з явною можливістю повтору. Зберігайте номер очікуваної сторінки окремо, доки не знатимете результату, й обробляйте порушення порядку відповідей у логіці застосунку. API не має курсорної кінцевої точки й не керує цим станом інтерфейсу замість вас. У /uk/#field-notes є приклади окремих станів завантаження та бюджету запитів.
