Choisir le minimum utile à la lecture
Dans l’application illustrative de randonnée, une fiche doit aider à décider si une référence historique mérite d’être ouverte. Commencez par le texte, la provenance, la date et le lien disponibles. L’API fournit des enregistrements à plat, pas un modèle de fiche prêt à l’emploi, et ne garantit pas tous les champs choisis. Prévoyez un petit adaptateur entre ces données et l’écran.
Traitez l’identité de la source séparément du texte affiché. Un id présent aide à suivre un élément, mais un titre ou extrait ne le remplace pas de manière fiable. Ne fusionnez pas des données distinctes parce qu’elles abordent la même expression. Gardez les données originales accessibles à l’adaptateur sans exposer la clé du service ou des détails de débogage dans la fiche.
Ne pas deviner un type ou titre manquant
Utilisez kind lorsqu’il est valide : post et comment appellent des libellés différents. Si le type manque ou n’est pas reconnu, choisissez un libellé neutre tel que Enregistrement archivé. Ne considérez pas automatiquement toute donnée inconnue comme un commentaire et ne présentez pas un commentaire isolé comme la conversation parente complète.
Imaginez un cas de test avec kind=comment, du texte lisible, sans titre ni lien exploitable. La fiche peut afficher Commentaire et Lien d’origine indisponible, puis le texte. Elle n’a besoin ni de titre généré ni d’URL inventée. Un autre cas peut avoir un long titre : autorisez son retour à la ligne ou proposez de le développer clairement. Ce sont des cas de test, pas des données dont on affirme l’existence dans l’archive.
Traiter le texte comme non fiable
Échappez correctement le texte non fiable avant de l’insérer dans l’interface. Conservez les sauts de paragraphe utiles, sans interpréter un contenu arbitraire comme des instructions HTML. Si vous ajoutez Markdown plus tard, choisissez et testez une politique de rendu limitée. Le texte brut constitue une première version valide et évite de promettre une mise en forme non réalisée.
Validez le lien avant de le rendre actif et traitez sa valeur absente ou inutilisable comme telle. Indiquez clairement la destination externe. Donnez aux actions des libellés lisibles, un accès au clavier et un ordre de focus cohérent. Une infobulle ne suffit pas à expliquer une date ou un lien indisponible à tous les lecteurs.
Rester exact sur les dates et le contexte
Si une date de création exploitable existe, présentez sa signification et son format de façon cohérente. Sinon, indiquez Date indisponible. Ne copiez pas la date du parent sur un commentaire : les deux textes n’ont pas nécessairement été créés ensemble. Une date de récupération locale décrit la consultation, pas l’âge de la discussion originale.
Lorsque parent_id ou link_id est présent, un regroupement local peut relier les données déjà reçues. Ces champs ne récupèrent pas les ancêtres absents, ne prouvent pas une conversation complète et ne fournissent pas de nouveau filtre. L’API actuelle n’expose aucun filtre parent_id ou link_id. La fiche peut signaler le contexte manquant sans reconstruire une conversation fictive.
Séparer les contrôles de liste de l’adaptateur
La pagination de la liste doit lire pagination.has_more et respecter le plafond de pages. N’activez ou désactivez pas Afficher la suite uniquement parce que pagination.relation vaut eq ou gte : cette relation décrit le total, pas la continuation. Un total inconnu ou exprimé en borne inférieure ne prouve pas non plus que les éléments visibles sont invalides.
Un tableau data vide dans une réponse réussie relève de l’état vide de la liste, pas d’une fiche d’erreur ; il coûte toujours un crédit. Incluez dans les tests proposés un titre long, un texte absent, une date absente, un lien inutilisable et un type inconnu, puis examinez l’affichage étroit. Ce sont des contrôles pour votre future réalisation, pas des tests effectués par ce guide. Retrouvez sur /fr/#field-notes les dates et les états.
