読むかどうかを判断できる最小限の表示を選ぶ
説明用のハイキングアプリでは、過去の参照資料を開くかどうか判断できるカードを目指します。まず、存在する本文、出典の情報、日付、利用できるリンクを使います。APIは完成したカードモデルではなく平坦なレコードを返し、選んだフィールドがすべて存在するとは保証しません。レコードと画面の間に、小さな変換処理を設けてください。
出典の識別と表示文は別に扱います。idが存在すればレコードの追跡に役立ちますが、タイトルや抜粋は確実な識別子の代わりにはなりません。同じ語句を扱うからといって、別のレコードをまとめてはいけません。カードにサービスの認証情報やデバッグ用の内部情報を出さずに、変換処理から元データを参照できるようにします。
欠けた種類やタイトルを推測しない
有効なkindがあれば使い、postとcommentで表示を分けます。kindがない、または認識できない場合は、中立的な「アーカイブレコード」というラベルにします。不明なレコードをすべてコメント扱いにしたり、単独のコメントが親の議論全体を表すように示したりしないでください。
kind=commentで、読める本文はあるもののタイトルも利用できる出典リンクもない、というテスト用データを考えます。「コメント」「出典リンクなし」と示した後に本文を表示できます。生成した見出しや架空のURLは不要です。別のテスト用データには長い投稿タイトルを入れ、折り返すか、明確な展開操作を用意します。これらはテスト用の例であり、アーカイブに存在すると主張するレコードではありません。
文章を信頼できない入力として表示する
信頼できない文章は、安全にエスケープしてから画面へ挿入します。意味のある段落区切りは保ちますが、任意のレコード内容をHTMLの指示として解釈してはいけません。後でMarkdown対応を追加するなら、許可する表現を限定した表示方針を選び、テストしてください。最初はプレーンテキスト表示でもよく、未実装の書式機能を約束せずに済みます。
出典リンクは操作可能にする前に検証し、ない値や使えない値は欠けているものとして扱います。外部リンクの行き先を明確に示してください。操作には読めるテキストラベルを付け、キーボードで利用できるようにし、適切なフォーカス順を保ちます。日付やリンクがない理由をすべての読み手に伝えるには、ツールチップだけでは不十分です。
日付と会話の背景を正直に扱う
利用できる作成時刻があれば、その意味と書式を一貫して示します。なければ「日付不明」と表示します。親投稿の時刻をコメントにコピーしてはいけません。2つの内容が同時に作成されたとは限らないためです。アプリが記録した取得日は、取得という操作の日付であり、元の議論の古さではありません。
parent_idまたはlink_idがあれば、取得済みのレコードをローカルで関連付けられる場合があります。これらの値は、欠けた祖先の復元、完全なスレッドの確認、新しいクエリフィルターの提供を意味しません。現在のAPIにはparent_idやlink_idのフィルターはありません。カードでは会話を作り上げることなく、背景が欠けていると示せます。
一覧の操作はカード変換処理から分ける
一覧全体のページネーションではpagination.has_moreを読み、ページ上限を守ります。pagination.relationがeqかgteかだけで「さらに表示」を有効・無効にしてはいけません。relationは総数についての情報であり、続きの操作を制御する値ではありません。総数が下限値または不明でも、表示中のレコード自体が無効だという証拠にはなりません。
正常な空のdata配列は、エラーカードではなく一覧の結果なし状態で扱い、それでも取得クレジットを1消費します。テスト用データの確認には、長いタイトル、本文欠如、日付欠如、利用できないリンク、不明なkindを含め、狭い画面でどう表示されるかを調べます。これは今後の実装で行う確認であり、このガイドが実行したテストではありません。出典の古さや状態設計は/ja/#field-notesを参照してください。
