一つのプレビューに範囲を絞る
この手順では小さな過去コメントのプレビューを作ります。fetchが利用できるNode.jsバックエンドで要求を実行し、そこでprocess.env.REDDIT_FETCH_API_KEYを読み込みます。設定がなければアーカイブへ接続する前に処理を止めてください。利用者へ返すのは画面用に整えた情報であり、サーバーが認証に使った秘密情報ではありません。エラーメッセージにもキーを含めないようにします。
接続先はhttps://api.redditfetch.com/v1/comments?subreddit=javascript&limit=3に固定し、例えば{"X-API-Key": key}をヘッダーとして渡します。Authorization: Bearer <key>も有効です。ブラウザーから来た任意のURLで接続先を置き換えないでください。独自経路のアクセス権と呼び出し回数はアプリケーション側で管理します。訪問者が有料の再取得を開始できる場面と、保存結果を見せる場面を分けておきましょう。
HTTP応答とネットワーク例外を分ける
ネットワーク処理が拒否されると、await fetchを囲むcatchへ進みます。その場合、分類に使えるHTTP応答は得られていません。一方、HTTP 401や402はPromiseが正常に完了しても返ります。まずresponse.okを見て、非成功ステータスを処理してから本文の扱いを決めてください。認証エラーの本文を、成功したコメント一覧として読もうとしないことが大切です。
HTTP 400ではパラメーター、401ではキー、402では残高を確認します。429なら必要に応じて待機を挟み、回数を限定して再試行できます。すべての失敗を無条件に繰り返さないでください。サーバーで課金対象の取得が成功した後に接続が切れる場合もあります。したがってローカルの例外は無課金の証拠ではなく、成功した再試行には別のクレジットが必要です。
JSONを読めた後も検証する
HTTP成功の分岐でもawait response.json()は失敗することがあります。内部の診断では、これを通信そのものの失敗と区別します。その後、期待する応答構造と、dataが配列であることを確認してください。JSONを解釈できたというだけでは、各記録に使える本文があることや、画面に必要なフィールドが適切な型であることは確認できません。カードへの変換は、その検証が済んでから行います。
断片から正直な表示状態を作る
プレビューに使うフィールドだけを変換します。本文がない場合と空文字の場合を区別し、利用できる識別子は元の記録をたどるために残し、内容はテキストとして表示してください。コメントは平坦な断片です。関係を示す任意フィールドがあっても完全なスレッドの証拠にはならず、3件取得したことから全返信を取得済みとは判断できません。
読み込み中、準備完了、空、失敗の状態をローカルで定義します。検証済みの空配列は、この要求から記録が返らなかったことを意味します。記録は届いたものの表示用検証をすべて通らなかった場合は、別の原因として診断に残します。更新に失敗したとき以前のプレビューを見せ続けることもできますが、保存済みのコピーであると明示し、新たに取得できたようには見せないでください。
次の呼び出しが必要か判断する
ローカルの進捗を進める前に、検証済み結果を要求パラメーターと一緒に保存します。コピーの再利用に新たな取得は不要ですが、成功した更新は空でも1クレジットです。アーカイブ順は時系列順ではありません。後から1要求最大100件、1条件最大100ページへ範囲を広げても、完全な網羅性や会話全体を取得できた証明にはなりません。
フィールドと合計の意味はドキュメント、費用は料金ページ、アカウント設定はキーのページを参照してください。公開かつ課金対象外の/v1/statusは静的なサービス説明であり、アーカイブの利用可能性を検査するものではありません。断片が過去の記録であることを画面に残し、ライブ更新、将来も同じ応答が得られること、完全な会話が揃うことを約束しないようにします。
