ブログのNext14対応+App Router対応

社用プロジェクトでは自分主導ですでにプロダクトのApp Router化をすませていたため、
ぱっとできるだろうという感覚がありブログのApp Router化を進めたところ数時間で終了した。

巷に転がっている「とりあえず"use client"をつけまくる」方式は好きではないので
既存で使いにくい箇所は一旦削ぎ落とす形で地道にやったので記録を残しておく。

手順

• rootの任意の場所にcreate-next-appで最新nextプロジェクトを作成
• クライアント側でないとできない処理を洗い出し、単コンポーネントへ格納
• 上以外はすべてRSC側で処理を実施し、クライアント側の責務を限定化

package.jsonで1からアップデートしていく方法もあったが、こちらだと経験上依存が多いほど
パターン分岐が増えめんどくさくなるのでnextの基礎から移行していったほうが早いという判断で
効率のいい形でpage.tsxを中心に設計。Recoilは業務でもかなり辛みを産んでおり、
ブログレベルのアプリケーションだとクライアント側の1Stateくらいで足りるため採用しない形とした。

クライアント側に任せたい処理はCSSのバインディングと状態保持、リアクティブなページ遷移くらいだったので
その3点に関してはクライアント側コンポーネントに任せ、それ以外はクライアント側で行えるよう処理を移動。
重い処理は記事のmd加工処理くらいだが、「クライアント側でやった方がいい処理」をまとめることにより
あとはサーバー側でと言う流れが作りやすくなったため高速で実装を進めることができた。

業務と違って楽だったこと(⇔業務だとつらいところ)

• ライブラリによっては剥がしが非常に面倒(特にCSS)
• 元のコンポーネント分割粒度が適正でないと、変更必要ファイルが増える
• App Router有利になるよう設計を変える必要がある(サーバー側に寄せる)

業務では初期にemotionを使用していたため、NextのApp Router対応実施時点でアプデが間に合っておらず
かなりめんどくさい状況になっていた。その際はcss modulesへの転換を実施したためかなりの時間がかかった。
またそれ以外にもApp Routerに持っていくと普段は出ていないバグが出るようなライブラリもいくつかあったため、
外部依存をできるだけやめる(またはクライアント側で強制的に使うようにする)という対応にかなり時間がかかった。
(直近で覚えているのだと emotion / tsyringe / next-router)

またもともとの設計がマテリアルデザイン的にめちゃくちゃ小さいコンポーネントが多かったため、
単純な"use client"をつけるだけの作業も結構骨が折れた。コンポーネント粒度議論についてはここで触れないが、
あまりマテリアルデザインで有利になったことがないので汎用性を重視するより最小公倍数的に単一の責務を満たせるような
コンポーネント設計をしていったほうがリファクタリング・可読性の面で有利だと思う。

そしてPages Routerのサーバー側処理としてgetServerSidePropsには意図して重そうな処理を書いていたと思うが、
RSCで今までより直感的に非同期が書けるようになったため「クライアント側でやらないといけない処理」以外は
積極的にサーバー側に処理を寄せて、クライアント側では操作インターフェース・描画する層としてやるべきことだけを
分離した設計にすることが必要になった。

以前から上の思想で実装をされていないものについてはApp Routerの恩恵を受けにくいだけではなく、
置き換えだけで時間かかるので置き換えない＝Next(React)の最新から遠ざかっていく可能性があるため、
フロントエンドエンジニアとしては積極的に情報を取りに行き、アップデートに追従していきたい。

このブログもNext14へのアップデート飲みは完了したが、まだServer Actionの使用に至っていないため、
こちらについても早めにキャッチアップして効果的に使えるようにしていきたい。