Reddit App API
DE

Reddit App API · 07 / 08

Jede Karte soll den tatsächlich erhaltenen Datensatz erklären

Gestalten Sie Diskussionskarten, die Quellenidentität erhalten, fehlende Felder behandeln und fremden Text sicher maskieren, ohne Titel, Threads oder Suchergebnisse zu erfinden.

Die kleinste nützliche Lesefläche wählen

In der beispielhaften Wander-App soll eine Karte bei der Entscheidung helfen, ob ein historischer Verweis geöffnet wird. Beginnen Sie mit vorhandenem Text, Quellenkontext, Datum und nutzbarem Link. Die API liefert flache Datensätze, kein fertiges Kartenmodell, und garantiert nicht jedes gewünschte Feld. Bauen Sie einen kleinen Adapter zwischen Datensätzen und Bildschirm.

Trennen Sie die Quellenidentität vom Anzeigetext. Eine vorhandene Datensatz-id kann der App beim Verfolgen eines Eintrags helfen; Titel oder Ausschnitt ersetzen diese Identität aber nicht zuverlässig. Verschmelzen Sie verschiedene Datensätze nicht, nur weil sie dieselbe Formulierung behandeln. Halten Sie Originaldaten für den Adapter verfügbar, ohne Dienstzugangsdaten oder interne Debug-Informationen in der Karte offenzulegen.

Fehlende Art oder Titel nicht erraten

Nutzen Sie einen gültigen kind-Wert, wenn vorhanden: post und comment ermöglichen unterschiedliche Beschriftungen. Fehlt die Art oder ist sie unbekannt, wählen Sie neutral Archivierter Datensatz. Machen Sie nicht jeden unbekannten Datensatz standardmäßig zum Kommentar und erwecken Sie nicht den Eindruck, ein einzelner Kommentar stehe für seine gesamte übergeordnete Diskussion.

Betrachten Sie eine vorgeschlagene Test-Fixture mit kind=comment, lesbarem Text, ohne Titel und ohne nutzbaren Quellenlink. Ihre Karte kann Kommentar und Quellenlink nicht verfügbar anzeigen, danach den Text. Sie braucht weder eine generierte Überschrift noch eine erfundene URL. Eine andere Fixture könnte einen langen Beitragstitel haben; lassen Sie ihn umbrechen oder bieten Sie eine klare Aufklappmöglichkeit an. Das sind Testbeispiele, keine behaupteten Archivdatensätze.

Fremden Text als nicht vertrauenswürdigen Inhalt darstellen

Maskieren Sie nicht vertrauenswürdigen Text vor dem Einfügen in die Oberfläche sicher. Erhalten Sie sinnvolle Absatzumbrüche, behandeln Sie beliebigen Datensatzinhalt aber nicht als HTML-Anweisungen. Falls Sie später Markdown unterstützen, wählen und testen Sie eine eingeschränkte Darstellungsrichtlinie. Reiner Text ist eine gültige erste Version und vermeidet das Versprechen nicht implementierter Formatierung.

Validieren Sie einen Quellenlink, bevor Sie ihn bedienbar machen, und behandeln Sie fehlende oder unbrauchbare Werte als fehlend. Beschriften Sie deutlich, wohin externe Links führen. Sorgen Sie für lesbare Aktionsbeschriftungen, Tastaturzugang und eine sinnvolle Fokusreihenfolge. Ein Tooltip allein erklärt nicht allen Lesenden ein fehlendes Datum oder einen fehlenden Link.

Daten und Gesprächskontext ehrlich darstellen

Ist ein brauchbarer Erstellungszeitstempel vorhanden, zeigen Sie seine Bedeutung und Formatierung konsistent. Andernfalls geben Sie Datum nicht verfügbar an. Kopieren Sie nicht den Zeitstempel des übergeordneten Beitrags auf einen Kommentar: Beide Inhalte müssen nicht gleichzeitig erstellt worden sein. Ein von Ihrer App vermerktes Abrufdatum beschreibt den Abruf, nicht das Alter der ursprünglichen Diskussion.

Sind parent_id oder link_id vorhanden, können bereits erhaltene Datensätze lokal gruppiert werden. Ihre Existenz liefert weder fehlende Vorfahren noch einen vollständigen Thread oder einen neuen Abfragefilter. Die aktuelle API bietet keine Filter für parent_id oder link_id. Eine Karte kann fehlenden Kontext benennen, ohne ein Gespräch vorzutäuschen.

Listensteuerung außerhalb des Kartenadapters halten

Die Paginierung der Liste sollte pagination.has_more lesen und die Seitengrenze beachten. Aktivieren oder deaktivieren Sie „Mehr anzeigen“ nicht allein danach, ob pagination.relation eq oder gte ist: Diese Relation beschreibt die Gesamtzahl, nicht die Fortsetzungssteuerung. Eine Untergrenze oder unbekannte Gesamtzahl beweist ebenso wenig, dass die sichtbaren Datensätze ungültig sind.

Ein erfolgreiches leeres data-Array gehört in den Leerzustand der Liste, nicht in eine Fehlerkarte; es kostet weiterhin einen Abruf-Credit. Nehmen Sie in die geplante Fixture-Prüfung einen langen Titel, fehlenden Text, fehlendes Datum, unbrauchbaren Link und unbekannte Art auf und prüfen Sie die Darstellung auf schmalen Bildschirmen. Das sind Prüfungen für Ihre künftige Umsetzung, keine von diesem Leitfaden ausgeführten Tests. Unter /de/#field-notes finden Sie Hinweise zu Quellenalter und Zustandsdesign.