レンダリングの変化点

半分以上AIにお任せでしかも短期間の突貫工事で作ったためいまのところメンテナンス性が最悪のこのブログ。
なんでそこまで可読性が低いのか、なんとなく原因が分かりました。
それは自分がNext.jsの最新版で変更された仕様の内実をまるっきり勘違いしていたことによります。

同じNext.jsで作ったピクチャレ大会はNext.js ver.13を使って作りました。
当時はプロジェクト作成時のフォルダ構造を「Pages Router」か「App Router」か選択できたのですが、
前者は従来からあるシステムであるのに対して後者は最近できたばかりの最新システム。
前者の方がネットに落ちているノウハウの量も多いだろうと思いPages Routerを選択しました。
しかしその後、公式がApp Routerを全面的に推奨するようになり、
たった１年余りでPages Routerは古いものというような風潮に。
そこで４代目本家ブログの制作にあたってはApp RouterとTypescriptを採用することにしました。
当時はルーティングのフォルダが「pages」か「app」の違いだろうというくらいにしか考えておらず、
しかもAIにほとんどお任せなのでそんな浅い知識でも動いてしまったんですね。

実際にはこれらのシステムの違いは
もはや違うフレームワークと言っても過言ではないほど変更箇所が多く、もっとも大きな違いは
App Routerはページ用のスクリプトが原則すべてサーバーサイドレンダリング（SSR）になるという点です。
SSRとは、サーバーで諸々の変数を処理してからHTMLを出力してクライアントに渡す方式です。
一方、クライアントのブラウザで諸々の処理を行う方式をクライアントサイドレンダリング（CSR）と言います。
Pages Routerでは専用の関数によってそれぞれの役割が明確に分かれていて、
まずgetServerSideProps関数でサーバーサイド処理を実行してその戻り値を取得し、
それに基づいてクライアントサイドで処理する部分を書くというやり方ができました。
これはPHPにおけるwebアプリの書き方にもよく似ていて直感的で分かりやすいです。

しかしApp Routerは全部サーバーサイドで処理するので、そういった従来の書き方が通用しないことになります。
ここで問題になるのが、ページを表示してからボタン押下などに連動して値を変更したいような場合。
そういう処理はクライアントサイドでしか処理できません。
そこで、App Routerではそういう部分はコンポーネント（部品）化して個別に処理することになります。
コンポーネントもデフォルトではSSRですが、
先頭行に"use client";とつけることで特別にクライアントで処理してくれます。
ファイル単位で処理を分けろということですね。
Pages RouterではコンポーネントはSSRできなかったので、そこは進歩した点です。
まあいずれにしろ、Pages Routerを知っているからと言ってApp Routerを使いこなせるわけではなく、
むしろフレームワークとしてイチから学習し直さなければならないレベルで変化点が多いです。
素直にPages Routerで開発するべきだったのかもしれない。

そんなことも理解せずに開発を無理やり進めた結果、
あらゆるページで動的な仕組みを導入できないサイトが完成してしまったというわけです。
そして後々useStateを利用する仕組みを導入しようとしたときに壁にぶち当たり半ば挫折していたわけですが、
その原因はApp Router移行時による仕様変更であると今回ハッキリと分かりました。
とにかく締め切りに追われて見切り発車で進めるとこうなってしまうという教訓ですね。

今回を機にApp Routerの仕様もだいぶ理解できたので、
４代目ブログのフロントエンドはいずれ根本的に作り直すかもしれません。
まあ動的な機能も必要ないテキストサイトなので支障ないと言ってしまえばそれまでなのですが、
そう言ったこととは無関係にとにかく動線も安定性も最悪なので……。
それにApp Routerの仕様を知ったことでにわかにプログラミングしたい欲の復活も感じています。
やはりこういうのは技術に触れることが一番大事なのかもしれない。