Mantén pequeña la siguiente acción
Supongamos que la app ilustrativa solicita offline maps en hiking con limit=3 y page=1. El lector abre las referencias devueltas y decide si otro grupo le ayudaría. Mostrar más debe solicitar la página siguiente para esa misma pregunta. No debe iniciar silenciosamente un rastreo de todas las páginas ni cambiar la consulta mientras mantiene los resultados anteriores en pantalla.
La señal visual es un control Mostrar más que aparece cuando la respuesta permite otra página. Impide activaciones repetidas mientras la acción esté pendiente y conserva accesibles las referencias ya mostradas. Cada solicitud de página correcta consume un crédito, incluso si queda vacía. Detenerse antes de pedir otra página evita esa solicitud futura; salir de la pantalla no garantiza cancelar ni reintegrar una solicitud ya enviada.
Conserva unido el estado de la solicitud
Mantén q, subreddit, los demás filtros elegidos y limit sin cambios al incrementar page. Si el lector cambia la expresión o el intervalo de fechas, empieza una nueva secuencia en la página 1. Mezclar una segunda página de otra pregunta con la lista anterior hace engañoso el historial de lectura, aunque ambas solicitudes tengan éxito.
El archivo utiliza el orden _doc. No es orden cronológico, de relevancia ni de puntuación; min_score filtra, no ordena. Puedes reordenar para la presentación los registros ya obtenidos, pero eso no identifica las coincidencias más recientes o mejores de todo el archivo. Las solicitudes repetidas de páginas no incluyen una garantía de instantánea estable.
Usa la respuesta, no un bucle que busque una página vacía
pagination.has_more se basa en un registro adicional de comprobación cuando la ventana lo permite. Ofrece la siguiente acción solo si has_more es true y la página es inferior a 100. No sigas solicitando hasta encontrar vacío: el servicio ya expone una señal de continuidad y las solicitudes correctas adicionales cuestan créditos.
Lee pagination.total junto con pagination.relation. eq significa recuento exacto según la semántica de esa respuesta; gte es un límite inferior, no una estimación estadística; unknown no ofrece un total fiable y puede acompañar a null. En una primera respuesta hipotética que muestre tres registros con total 4 y relation gte, podrías indicar al menos cuatro coincidencias. No debes afirmar que son exactamente cuatro.
Reconoce el límite de la ventana
Los límites son 100 registros por solicitud y 100 páginas. En la página 100 con limit 100, una última página completa no deja espacio para comprobar un registro adicional. Por ello pagination.window_exhausted puede ser true mientras has_more es false y relation es gte. En ese límite, has_more false no demuestra que el archivo carezca de más coincidencias.
Una página vacía posterior a la primera tampoco establece un total global; el gateway marca el total como desconocido en ese caso. Describe el límite real, por ejemplo Se alcanzó la ventana de esta búsqueda, en lugar de Todas las conversaciones cargadas. Acotar una consulta puede organizar más trabajo, pero no convierte solicitudes limitadas en una exportación exhaustiva.
Combina con cuidado y permite recuperarse del fallo
Si existe un identificador real del registro, tu app puede usarlo para evitar mostrarlo dos veces en la lista acumulada. Elige reglas de identidad basadas en los campos recibidos; no inventes un ID cuando falte ni combines registros distintos solo porque su texto se parezca. Eliminar duplicados localmente no prueba que la lista restante esté completa.
Una solicitud fallida de página siguiente debe conservar los registros previos y la consulta, con una opción explícita de reintento. Mantén separado el número de página pendiente hasta conocer el resultado y gestiona las respuestas fuera de orden en tu propia lógica. La API no proporciona un endpoint de cursor ni gestiona ese estado visual. Vuelve a /es/#field-notes para ejemplos de carga independiente y presupuesto de solicitudes.
