Define los estados antes de dibujar el indicador de carga
Este es un flujo propuesto para una app de senderismo propia, no un registro de comportamiento observado de la API. La persona introduce offline maps, solicita conversaciones históricas y espera. La app debe distinguir el formulario sin usar, la solicitud sin resolver, los registros devueltos, una respuesta vacía correcta y un fallo. Un único panel en blanco no puede explicar todas esas situaciones.
Empieza con una pantalla neutra que explique qué se buscará. Escribir no tiene por qué generar una solicitud. Tras un envío explícito, guarda la pregunta asociada a esa solicitud y muestra una etiqueta de carga. Conserva legible la entrada e impide que las pulsaciones repetidas envíen varias veces la misma acción. La animación indica espera, no demuestra avance por el archivo.
Vincula la respuesta tardía con su pregunta
Imagina que la persona cambia la entrada a regiones descargadas mientras sigue pendiente la solicitud de offline maps. Es una interacción ilustrativa, no un ejemplo de búsqueda recuperada. Tu app debe decidir si espera, inicia otra solicitud o permite cancelar la vista. Sea cual sea la elección, la respuesta anterior no debe convertirse sin aviso en la respuesta a la expresión nueva.
Asocia cada solicitud a la entrada enviada dentro del estado de tu aplicación. Cuando llegue, comprueba si aún corresponde mostrarla en la vista actual. Descartarla de la pantalla no equivale a cancelar el trabajo del servidor: una solicitud ya enviada podría terminar correctamente y cobrarse. Prueba esa diferencia en tu implementación.
Trata una respuesta vacía correcta como un resultado
Con registros devueltos, muestra los campos disponibles y conserva la etiqueta de fuente histórica. Con un array data vacío, usa un mensaje distinto que explique que esta solicitud no devolvió registros. Ofrece editar la expresión o los filtros y consérvalos para que el lector pueda decidir con conocimiento. No sustituyas una respuesta vacía por publicaciones populares inventadas.
Las recuperaciones vacías correctas cuestan un crédito, igual que las respuestas correctas con registros. Eso justifica que los cambios de consulta sean intencionales, no ocultar las respuestas vacías como errores. Evita afirmar que no existe ninguna conversación relevante; el archivo es incompleto y la respuesta corresponde a una consulta y una ventana acotadas.
Dirige el problema técnico al operador
Una respuesta 400 exige comprobar la entrada de la solicitud. Si la app suministró una fecha inválida o un parámetro no admitido, no culpes al lector de un error del contrato del backend. Un 401 indica una clave del servicio ausente o inválida; recargar la app o pedir iniciar sesión no necesariamente corrige esa credencial.
Un 402 indica créditos insuficientes en la cuenta del servicio. Dirige esa decisión al operador en lugar de mostrar una factura a quien camina. Un 429 requiere respetar Retry-After y reducir las solicitudes repetidas. Como la app puede compartir una cuenta entre varios lectores, no afirmes automáticamente que una sola persona provocó el límite.
Separa un fallo conocido de un resultado desconocido
El gateway devuelve 502 cuando falla una recuperación en la fuente ascendente. Su crédito reservado se libera o queda señalado como pendiente de conciliación. Conserva la consulta y cualquier página ya visible, y ofrece un reintento acotado. Los reintentos automáticos repetidos pueden generar más solicitudes sin ayudar al lector a entender lo sucedido.
Si tu app nunca recibe respuesta, puede desconocer si el servidor falló o terminó. Registra esa incertidumbre para la conciliación; no muestres una afirmación definitiva de reintegro o éxito. La ruta pública /v1/status es una comprobación estática de alcance y respuesta HTTP, así que no resuelve esa duda ni certifica el buen estado de la búsqueda.
Revisa las transiciones, no solo las capturas
Recorre la secuencia propuesta con quien gestiona la app: enviar, editar mientras se espera, recibir una respuesta vacía, reintentar tras un fallo, cargar otra página y salir de la pantalla. En cada transición, identifica la entrada conservada, el contenido visible y la siguiente acción. Una maqueta atractiva no demuestra que esas transiciones funcionen.
Mantén los diagnósticos del operador, las respuestas originales del servicio y las credenciales fuera de los mensajes públicos. Ofrece al lector contexto suficiente para continuar preparando el viaje sin depender de una función de conversaciones no disponible. Vuelve a /es/#field-notes para las decisiones de presupuesto de solicitudes y Mostrar más que dan forma a este flujo.
