Elige lo mínimo útil para leer
En la app ilustrativa de senderismo, la tarjeta debe ayudar a decidir si abrir una referencia histórica. Empieza por texto disponible, contexto de origen, fecha y un enlace utilizable. La API devuelve registros planos, no un modelo de tarjeta terminado, y no garantiza todos los campos que elijas. Crea un pequeño adaptador entre los registros y la pantalla.
Trata la identidad de origen por separado del texto mostrado. Un id disponible puede ayudar a tu app a seguir un elemento, pero un título o fragmento no sustituye su identidad de forma fiable. No combines registros distintos porque mencionen la misma expresión. Mantén los datos originales disponibles para el adaptador sin exponer credenciales del servicio ni detalles internos de depuración en la tarjeta.
No adivines un tipo o título ausente
Usa un valor kind válido cuando exista: post y comment permiten etiquetas diferentes. Si kind está ausente o no se reconoce, utiliza una etiqueta neutra como Registro archivado. No trates automáticamente todo registro desconocido como comentario ni sugieras que un comentario aislado representa toda la conversación de la que procede.
Considera un caso de prueba propuesto con kind=comment, texto legible, sin título ni enlace utilizable. Su tarjeta puede decir Comentario y Enlace de origen no disponible, seguido del texto. No necesita un titular generado ni una URL inventada. Otro caso puede tener un título largo de publicación: deja que se distribuya en líneas o proporciona una forma clara de ampliarlo. Son ejemplos de prueba, no registros cuya existencia se afirme.
Trata el texto como contenido no confiable
Escapa de forma segura el texto no confiable antes de incorporarlo a la interfaz. Conserva los saltos de párrafo significativos, pero no interpretes el contenido arbitrario de un registro como instrucciones HTML. Si añades Markdown más adelante, elige y prueba una política restringida de presentación. Mostrar texto plano es una primera versión válida y evita prometer un formato que no has implementado.
Valida el enlace de origen antes de hacerlo pulsable y trata los valores ausentes o inutilizables como tales. Etiqueta claramente el destino de un enlace externo. Mantén etiquetas legibles en las acciones, acceso por teclado y un orden de foco razonable. Un mensaje emergente por sí solo no basta para explicar a todos los lectores una fecha o enlace no disponibles.
Describe con precisión fechas y contexto
Si hay una marca de creación utilizable, muestra su significado y formato de manera coherente. De lo contrario, indica Fecha no disponible. No copies la fecha de la publicación padre a un comentario: ambos textos no tienen por qué haberse creado juntos. La fecha de recuperación registrada por tu app describe la consulta, no la antigüedad de la conversación original.
Cuando existan parent_id o link_id, una agrupación local puede conectar registros ya presentes en los resultados. No recuperan antecesores ausentes, demuestran un hilo completo ni añaden un filtro. La API actual no expone filtros parent_id ni link_id. La tarjeta puede reconocer que falta contexto sin construir una conversación ficticia.
Separa los controles de lista del adaptador de tarjetas
La paginación de la lista debe leer pagination.has_more y respetar el límite de páginas. No habilites o deshabilites Mostrar más solo porque pagination.relation sea eq o gte: esa relación describe el total, no el control de continuación. Un total desconocido o de límite inferior tampoco prueba que los registros visibles sean inválidos.
Un array data vacío en una respuesta correcta corresponde al estado vacío de la lista, no a una tarjeta de error; sigue costando un crédito. En la revisión de casos propuestos incluye título largo, texto ausente, fecha ausente, enlace inutilizable y tipo desconocido; después comprueba el diseño en una pantalla estrecha. Son comprobaciones para tu implementación futura, no pruebas realizadas por esta guía. Vuelve a /es/#field-notes para las notas de fechas y estados.
