2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

はじめに

自分の音楽活動用の個人サイトを作っています。

最初は HTML と CSS だけで作っていました。

小さい個人サイトであれば、それで十分です。

実際、

  • プロフィールを書く
  • SNSリンクを置く
  • 作品リンクを並べる
  • 活動履歴を書く

くらいなら、HTML/CSSだけでも問題なく作れます。

ただ、活動が増えるにつれて、作品情報やリンク、Timelineの項目が増えてきました。

その結果、HTMLに直接書き続けるよりも、React + TypeScriptで整理した方が更新しやすいと感じるようになりました。

この記事では、小さい個人サイトをReact化してよかったことと、逆にReact化しなくてもよかったことを書きます。

もともとの構成

最初はかなりシンプルな構成でした。

index.html
style.css
assets/

HTMLに各セクションを書いて、CSSで見た目を整えるだけです。

これはこれでかなり良いです。

  • すぐ作れる
  • ビルド環境がいらない
  • 仕組みが単純
  • 静的ホスティングに置きやすい
  • 壊れにくい

個人サイトを最初に作るなら、むしろHTML/CSSだけの方が早いと思います。

つらくなってきたところ

作品が増えるとHTMLが長くなる

作品一覧は、だいたい同じ構造の繰り返しです。

<article class="work-card">
  <p class="work-category">Release</p>
  <h3>作品名</h3>
  <p>説明文</p>
  <a href="...">Listen</a>
</article>

これを作品ごとにコピーして書いていくと、HTMLがどんどん長くなります。

最初は問題ありません。

ただ、数が増えると、

  • クラス名の付け忘れ
  • リンクの修正漏れ
  • 表記ゆれ
  • セクションごとの構造のズレ

が起きやすくなります。

Timelineが管理しづらい

個人サイトでは、活動履歴を置きたくなることがあります。

たとえば、

  • リリース
  • レーベル参加
  • コレクティブ参加
  • サイト公開
  • プロジェクト開始

などです。

HTML直書きだと、項目を増やしたり並び替えたりするたびに、マークアップごと触る必要があります。

活動履歴は今後も増えていくので、ここはデータ化した方がよさそうでした。

データと見た目が混ざる

HTML直書きでは、作品情報と見た目の構造が同じ場所にあります。

<h3>Architecture of Afterglow</h3>
<p>Ambient / Glitch / Shoegaze...</p>
<a href="https://...">Bandcamp</a>

これは分かりやすい反面、情報だけを更新したいときにもHTML構造を触ることになります。

本当は、作品情報はデータとして管理したいと思いました。

const works = [
  {
    title: 'Architecture of Afterglow',
    description: 'Ambient / Glitch / Shoegaze...',
    url: 'https://...',
  },
]

表示はコンポーネントに任せて、情報は配列に追加するだけにしたい。

これがReact化した一番大きな理由です。

React化してよかったこと

コンポーネントに分けられた

React化したことで、サイトをセクションごとに分けられるようになりました。

Header
Hero
About
Works
Timeline
NowPlaying
Footer

HTMLだけで作っていたときは、ページ全体をひとつの大きなファイルとして見ていました。

React化すると、セクションごとに責任を分けられます。

これだけでも見通しがかなり良くなりました。

作品情報をデータ化できた

Worksセクションは、データとして管理するようにしました。

type Work = {
  title: string
  description: string
  url: string
  category: 'release' | 'single' | 'prototype'
}

const works: Work[] = [
  {
    title: 'Architecture of Afterglow',
    description: 'Ambient / Glitch / Shoegazeを中心にしたアルバム。',
    url: 'https://7g3n.bandcamp.com/album/architecture-of-afterglow',
    category: 'release',
  },
]

表示側では map します。

function WorksSection() {
  return (
    <section>
      <h2>Works</h2>

      <div>
        {works.map((work) => (
          <WorkCard key={work.title} work={work} />
        ))}
      </div>
    </section>
  )
}

カードはコンポーネントにします。

type WorkCardProps = {
  work: Work
}

function WorkCard({ work }: WorkCardProps) {
  return (
    <article>
      <p>{work.category}</p>
      <h3>{work.title}</h3>
      <p>{work.description}</p>
      <a href={work.url}>Listen</a>
    </article>
  )
}

これで、新しい作品を追加するときは works に1件追加するだけで済みます。

HTML構造をコピーして編集するより、かなり安全です。

TypeScriptでデータの形を守れる

TypeScriptを入れてよかったのは、データの形を固定できることです。

type WorkCategory = 'release' | 'single' | 'prototype'

このようにしておくと、想定していないカテゴリを入れたときに気づけます。

category: 'album'

小さいサイトでは、TypeScriptは大げさに見えるかもしれません。

でも、作品情報や活動履歴のように今後増えていくデータがある場合、型があると修正漏れに気づきやすくなります。

修正範囲が小さくなった

HTML直書きでは、作品カードの見た目を変えたいとき、同じような構造を何箇所も確認する必要がありました。

React化後は、WorkCard を修正すれば、すべてのカードに反映されます。

変更前:
  複数のHTMLをそれぞれ修正

変更後:
  WorkCardだけ修正

これはかなり楽でした。

更新しやすくなった

個人サイトは、作ったあとに更新しなくなることが多いです。

その理由のひとつは、更新が面倒になることだと思っています。

React化してデータと表示を分けたことで、

  • 新しい作品を追加する
  • 活動履歴を追加する
  • リンクを差し替える
  • 表示順を変える

といった作業がやりやすくなりました。

更新しやすい構造にしたことで、サイトを放置しにくくなったのは大きいです。

React化しなくてもよかったこと

一方で、全部をReact化する必要があったかというと、そうではありません。

静的な文章だけならHTMLで十分

プロフィール文やフッターのように、ほとんど変わらない部分はHTMLでも問題ありません。

Reactにしたからといって、そこが劇的に良くなるわけではありません。

一度書いたらほぼ変わらない文章
固定のリンク
単純なレイアウト

こういう部分だけなら、HTML/CSSで十分です。

小さいサイトならビルド環境が増える

React + TypeScript にすると、当然ビルド環境が必要になります。

Vite
TypeScript
npm scripts
dependencies
build
deploy

HTML/CSSだけなら不要だったものが増えます。

小さいサイトにとっては、この増加がデメリットになる場合もあります。

React化する判断基準

今回やってみて、React化するかどうかは「サイトの規模」よりも「今後どれだけ更新するか」で考えるのがよいと思いました。

React化した方がよさそうなのは、こういう場合です。

作品や記事が増えていく
同じ構造のカードが何度も出てくる
活動履歴を更新していく
データと表示を分けたい
今後セクションが増える

逆に、HTML/CSSのままでよさそうなのは、こういう場合です。

1ページだけの固定プロフィール
ほとんど更新しない
同じ構造の繰り返しが少ない
ビルド環境を持ちたくない

Reactは便利ですが、すべての個人サイトに必要なわけではないと思います。

デザインは変えすぎないようにした

React化すると、つい動きやコンポーネントを足したくなります。

ただ、今回のサイトは技術デモではなく、音楽活動のための個人サイトです。

そのため、見た目は大きく変えすぎないようにしました。

  • 余白を残す
  • 情報を詰め込みすぎない
  • アニメーションを入れすぎない
  • 読みやすさを優先する
  • 個人サイトとしての温度感を残す

内部構造は整理しつつ、外側の空気感はできるだけ保つようにしました。

まとめ

小さい個人サイトを React + TypeScript でリファクタリングしました。

React化してよかったのは、

  • セクションをコンポーネント化できた
  • 作品情報をデータとして管理できた
  • Timelineを更新しやすくなった
  • TypeScriptでデータの形を守れるようになった
  • 同じHTMLを何度も書かなくてよくなった
  • 今後の更新に強くなった

という点です。

一方で、固定の文章やほとんど変わらない部分は、HTML/CSSだけでも十分だと思いました。

個人サイトは、作って終わりではなく、活動と一緒に少しずつ変わっていくものです。

だからこそ、見た目だけでなく、自分が更新し続けられる構造にしておくことが大事だと感じました。

2
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?