WORK

Webメディアサイトの構築

記事を読むための公開サイトを構築しました。管理画面で公開を選んだ記事だけがページになり、事前に生成して配信します。お問い合わせは、記事とは別の窓口として設けています。

概要

記事を読むための公開サイトです。記事の一覧と本文は静的なファイルとして配信し、管理画面で記事を扱い、問い合わせは読むページとは別の窓口にしています。公開するものだけが読むページに出ます。更新のたびに、読むページ、管理、連絡の受付を別々の手順で繋ぎ直さなくて済むように、同じサイトの中で役割を分けています。

読む人は公開された記事の一覧から本文へ進みます。管理画面では記事を扱い、公開するものだけが静的なページになります。問い合わせは本文の途中ではなく、別の窓口です。ヘッダーとフッターは共通で、記事のページからも同じ案内で問い合わせへ進めます。公開された記事だけが一覧と本文に出て、問い合わせは別の窓口です。

課題

読むページ、管理、問い合わせの公開手順が、更新のたびに分かれていました。記事を直したあと、一覧と本文のどちらを出し直すか、連絡の受付をどの入口に置くかが、作業のたびに変わっていました。下書きと公開中の記事が同じ場所に見えると、読む人に未完成の文章が出る心配もありました。問い合わせが記事の途中に混ざっていると、読むためのページと、連絡を受けるページの役割が区別できませんでした。

記事を直すたびに、一覧、本文、問い合わせのどれを更新するかを個別に判断していました。下書きが読むページに混ざると、未完成の文章が公開されているように見えました。問い合わせの入口が記事ごとに違うと、連絡先を探すところから読み手が止まっていました。更新手順が人の記憶に残っている状態でした。

対応

記事の一覧と本文を静的なファイルとして出します。管理画面では記事を扱い、公開するものだけが読むページに載ります。一覧から本文へ進み、読む人は公開された記事だけをたどります。問い合わせは記事の本文とは別の窓口にして、読むことと連絡することを分けています。ヘッダーとフッターはサイト全体で共通にし、記事のページでも同じ案内から問い合わせへ進めるようにしています。

公開の状態になった記事だけを静的なファイルとして出します。一覧はそれらの記事を並べ、本文はそのファイルを開いて読みます。管理画面では下書きや公開の状態を扱い、読むページとは分けています。問い合わせは共通の窓口へ進め、記事の本文の中に送信欄を混ぜていません。更新後は静的なファイルを出し直して、読むページを揃えます。

構成

ページは Astro と TypeScript で組んでいます。記事の一覧と本文は静的なファイルとして配信し、読むためのページを更新のたびに静的な成果物として出せるようにしています。管理画面は記事の作成と公開の状態を扱い、公開された記事だけが静的なページになります。問い合わせの窓口は読むページとは別の経路です。配信そのものは静的ファイルが担い、記事の本文をリクエストのたびに組み立てる構成にはしていません。

Astro がページの構造を作り、TypeScript がそのページのロジックを書きます。配信する成果物は静的ファイルで、記事の表示のたびにサーバーが本文を組み立てる構成ではありません。管理画面は記事の状態を変え、公開されたものだけが静的な一覧と本文になります。問い合わせの経路は読むページの生成とは分けています。

記事一覧