概要
本サイトの構築に使用したフレームワーク等を少しだけ深掘りしてみようと思います。
有り体に言うとNext.js+ヘッドレスCMSです。
フレームワーク
Next.jsを使用しています。選定理由は以下あたり。
- 表示高速化に向けた仕組みが整っている・追加されている
- React含め、動的サイト構築時のデファクトスタンダードとなりつつある
- 業務ではVue.jsばかり触っているのでReactのキャッチアップ
Astroあたりも検討しましたが、ブログ以外の動的なコンテンツも内包させる可能性があるため、より幅広い用途に適用しやすいNext.js側に倒しました。
CMS部分
Contentfulを利用しています。
選定の前提としては、
- マークダウンで書ける
- API等でマークダウンのままフロント側に渡せる
くらいです。
公式のクライアントSDKであるcontentful.js経由でデータ取得し、デプロイ時にSSGしています。
（SSGベースなのであまり問題ないと思いますが）全件・全プロパティを取得しているような状況なので、公式のGraphQLエンドポイントからクエリで取得するように変更してみようかな、と考えています。
ただし、タグのプロパティの取得に難がありそうな香り（詳しくは見れていないですが）なのであまりきれいな実装にならないような気はしています。
もしくはローカルファイルベースの管理に差し替えるかもしれません。
デザイン関連
コンセプト・イメージ等
- クリーン・プレーン
- 青系統が好きなので少し寒色寄りに
- 余白は気持ち多めでゆったり見れるように
- オーバレイ表示させる部分は透け感をもたせる
UIコンポーネント系
デザイン面の勉強目的や表現の自由度の観点から、デザイン込のコンポーネントは使用しませんでした。
唯一、アクセシビリティやキー操作対応への実装簡略化のため、ヘッドレスコンポーネントとしてRadix UI の primitivesを使用しています。
CSS
TailwindCSSを使用しています。
ReactにおけるCSS適用は複数の実装方法があり、悩ましいところなので所感としてのメリット・デメリットをまとめてみました。
メリット
- ユーティリティベース
- スタイルの依存先がほぼ要素1つに限定できるため、コンポーネント粒度を操作しやすい。
- ここ切り出したい/まとめたいとなったときに変更しやすい。
デメリット
- やはりクラス数が多くなると可読性は犠牲になります。
- が、複雑性はコンポーネントの切り方で緩和できる
- 親要素自体と、疑似要素などのクラスをまとめて記載したいケースなどで長さが顕著になってしまっています。
- animation,keyframesの定義はコンフィグ（
tailwind.config.ts)への定義が前提となる
ざっくり挙げるとこんなところでしょうか。
コンテンツ上、ロジックが絡む部分が少ないので、実現できなくて困る！みたいなケースには遭遇していません。
最悪設計変更したくなった場合も、コンポーネント単位でリファクタリングしていけばいいか、程度で捉えています。
目次
toxbotを使用しています。
現状、記事ページの右ペイン（PCのみ）に目次を表示しています。
モバイル向けの表示は未実装なのと、記事内トップにも目次を設置したいと考えていますが、未対応です。
素材系
商用フリーのものを採用しています。
| 使用箇所 | 公式サイトなど |
|---|---|
| フォント | Google Fonts |
| ロゴ | icons8 |
| アイコン | Phosphor Icons |
| 記事リード画像 | unsplash |
余談ですがプロフィール画像（ターミナル上に猫が乗っている）は猫ちゃん部分はフリーアイコン（ロゴ共通）、それ以外の部分は自作です。
デプロイ
VercelをGitHubと連携させて使用しています。
Next.jsのリリース元である点と、Tokyoリージョンをサポートしている、無料枠が十二分にある、あたりが主な選定理由です。
記事内容更新時のContentful側のWebhook等の設定については、 記事の執筆よりもサイトの構築的な部分の比重がまだまだ多い見込みのため、現時点では行っていません。
まとめ
以上、現時点での技術スタックについての雑記でした。
今後、優先して実装したい機能は以下辺りです。
- RSS対応
- 動的なOGP対応
- 共有系ボタン設置
- ページング対応
- モバイル向けの目次設置
- サイト内検索
継続して機能の改善や記事の拡充などを進めていきたいと思います。