🕌

Next.jsのエラーハンドリングについて調べた件

2024/04/26に公開

※PagesRouterではなく、AppRouterで調べた結果となるので留意してください。

現状のエラーパターン

ざっくりと上記のパターンかと。

上記の２パターンあって、対応方法が違うかもなのでドキュメントも自分が使っている方で読む必要がある。

error.tsxを置くと、layoutタグ以下に自動でReactのErrorBoundaryとして差し込まれる
- 【意見】勝手に差し込むと分かりづらいから、自分で書いた方が良く無いか？と思う
error.tsxは画面表示時にエラーがあった場合、表示される
- たまたまエラーが出た時の復帰用に、再実行するだけの関数も提供されている
エスカレーションも出来るので、最上位に１個置いておくだけで、全ページに仕込まなくて良い
global-error.tsxというものもある
- layoutタグ以下に差し込む関係上、最上位のlayout部分でエラーが出た場合に対応できないため作成された

globalのやつだけ仕込んで置いて、必要であれば各ページで仕込むスタイルが良いかな？と思った。

ボタンのonClickなどのイベント処理では、error.tsxは表示されない
- Provider用意して、ハンドリングするというHackもあるみたいだが、エラーがわかれば良いだけなら、Toastで良いのでは？と思う
- あと、開発時はデフォルトのToast表示があるので、そちらでスタックトレースは見れる

ログインしてなくてリダイレクト的なエラーハンドリング
- Next.jsのミドルウェアを設定して、ログイン判定やリダイレクトを行う
画面表示時にエラーが出る
- 主に404かシステムエラーだと思うから、汎用のerror.tsxを表示する
ボタン押下時にバリデーションエラーが出る
- Toastで警告表示を出して、該当の項目付近に詳細エラーを表示する
- 開発時は、Next.jsのトーストも出てきてスタックトレースも見れる
ボタン押下時にシステムエラーが出る
- Toastでエラー表示を出すだけ
- 開発時は、Next.jsのトーストも出てきてスタックトレースも見れる

Reactもそうだけど、Next.jsもフルスタックでは無いっぽいので、足らない部分は自前で揃える必要があります。
（今回で言うとイベント時に発生するエラーですね。）

どうせ自前で揃えるなら、フレームワーク使わずにライブラリ揃えて使ったほうがハンドリングしやすいし、フレームワークの変更に振り回されることもないです。

でも、みんなオレオレは嫌だとか、モダンとか最新が良いんだろうなぁと、思った次第です。
（数年経ったらレガシーと言われる業界なんだから、シンプルに作れば良いのでは？とか）

（今書いているコード自体が将来の人から見たらレガシーだと言うなら、せめてシンプルさや置き換え易さを念頭において実装すべきでは？と思っております）

（PHPはフレームワークごと廃れるのが多かったからか、フレームワークに依存しないように移植が容易になるように書いていこうという記事を見ることはあります。フレームワーク１強が続いている言語とかは、考えないんだろうなぁと思ったり）