このブログをNext.jsでリニューアルしました。

Before

• 手組みのReact SPA
• Webpackを自前で設定
• Reactstrapベース
• JavaScript
• クライアントサイドでfetchして記事表示

問題点

• Service Workerの設定が拙くて記事更新が不安定
• クライアントサイドのfetchなので表示が若干遅れる
• Webpackの設定見直したくない
• TypeScript使いたい

After

• Next.js + Material UI
• next build && next exportで静的化
• サイト内検索やページングだけクライアントサイドでfetch

実験的に入れたもの

guess.js

Google Analyticsのデータを使用してページ毎にprefetchの設定をしてくれるライブラリ。

GCPのクレデンシャルをNetlifyの環境変数にいれて、next buildでそれを使ったデータ取得する形で実装。

AWS Amplify使うならSecret Managerで管理が無難かも

next-pwa

next-offlineの方が有名っぽかったですが、こっちの方が最終更新日が近かったのであえて採用。

デフォルトである程度キャッシュ範囲設定してくれるので、小さいブログやサイトであれば数行追加するだけでいける。

react-schemaorg

JSON-LDを吐き出してくれるツール。詳しくはこちらの記事で。

react-cookie-consent

GDPRあたりで要求されるcookie利用同意系に利用。

同意画面の表示制御とcookieに回答結果を書き込む機能を提供してくれるので、香川県的な個別同意案件にも使えそうではある。

ハマったところ

window系プロパティの操作

SSGさせる関係上、この値を前提とした実装をするとビルドでこける。

locationとかcookieとかその辺で引っかかりやすい。

process.browserで判定してSSGの時は動かさないようにするのが吉。

ヘッダーでの検索フォーム

これのためだけにReduxをいれることに。いやHookのContextあたり使えばいけるだろうというのはわかってるんですけどね。なんとなくあの辺データフローが見えにくくなりそうで敬遠してる。（個人の趣味嗜好の問題）

Material UI with Next.js

Next.jsのLinkコンポーネントとMaterial UIのリンク系コンポーネントの相性が微妙によくない。サンプルコードにある属性を使おうとしたらd.tsには記載がないやつでTSエラーが出るというパターンもあったりで地味に辛かった。

この辺りはラッパーコンポーネントを使うことになるので、追々まとめます。

日本語パーマリンク

Gatsbyもだった記憶なので、SSG系の鬼門なのかも。作者が考慮してないだけだろうし、マルチバイト圏からのコントリビューターが増えれば解決するとは思うけど。

あまり時間かけたくなかったので、今回は日本語URLをビルド対象から外して、元記事のURLを変える形で対応。

NetlifyやAWS Amplifyあたりにリダイレクト書いてやれば404問題も多分大丈夫。

感想

個人のブログ程度であれば、GraphQLの知識求められるGatsbyよりNext.jsのSSGモードの方が気楽かもしれない。

とはいえフレームワーク側が一度データをストアしてくれて、そこに対するクエリを書くだけでいいという気楽さはGatsbyならではで、Next.jsの場合は都度getStaticPaths / getStaticPropsでfetchしないといけない煩雑さはある。

• 都度問合せ系 -> Nest.js
• 一旦集約してから取り寄せる系 -> Gatsby

ってイメージなので、データソースの数や種類が増えてくるとNext.jsのSSGモードは辛くなってくるかも。

今後

StripeとかAuth0あたりを遊びでいれてみるかもしれない。

レコメンドとか閲覧履歴とか、そういうのやってみたい気はするので。