技術ブログ改め、Qiitaの下書き

ブログをNext.jsベースに変更した

久しぶりの更新。
ブログの使用技術をReact+Next.jsに変更した。

使用技術

変更

  • Hyperapp v1 -> React
  • 自作フレームワーク? -> Next.js
  • nes.css -> mvp.css

続投

  • TypeScript

なぜ変えたか

Next.jsがSSGに対応し、getStaticPathsgetStaticPropsが気になったため。

なぜgetStaticPathsgetStaticPropsが気になったのか

以下のメリットがあるため。

  • ダイナミックルーティングをコンポーネント側で設定できる
  • データの加工処理を事前に行ってくれる

ダイナミックルーティングの設定について

SSGでダイナミックルーティングを行う場合、下記の設定が必要である。

  • ダイナミックに生成されるURL
  • 上記URLで使用するテンプレートと、それに渡すデータ

たいていのSSGツールの場合、上記は設定ファイルに記述する必要がある。しかし、Next.jsでは、pagesディレクトリ内のコンポーネントに記述する。

例)pages/blog/[slug].jsx
// ダイナミックに生成されるURLの一覧
export const getStaticPaths = async () => {
  const contents = getAllPosts() // 記事一覧の取得
  const paths = contents.map(v => `/blog/${v.slug}`)

  return { paths, fallback: false }
}

// コンポーネントで使用するデータ
export const getStaticProps = async ({ params }) => {
  const post = getPost(params.slug) // 記事データの取得

  const props = { post }

  return { props }
}

// 使用するコンポーネント
export default ({ post }) => {
  return <div>{/* ... */}</div>
}

コンポーネントの1つのファイルにまとまるのは便利。

なお、getStaticPathsgetStaticProps内では、node.jsで実行(ブラウザのAPI利用不可)されるが、importしたアセットはWebpackのローダーが適用される。 このブログでは、require.contextですべてのマークダウンファイルを取得し、mdx-loader等でHTML化して読み込んでいる。

最後に

Gatby.jsというフレームワークを触ったときに、pageディレクトリの自動ルーティングがあるのにダイナミックルーティングの設定は設定ファイルに書かなければいけないことに違和感があった。Next.jsでは、pagesディレクトリ内のコンポーネントのファイルでgetStaticPathsgetStaticPropsをexportするという方法を採用している。もし、このブログをまた自作フレームワークを採用する場合、ぜひ採用してみたい。