概要
Blazorで404ページを作成する方法を調べてみた。
記事に書いているが、懸念事項が多く、あまり参考にはならないと思われる。
プロジェクトの構成
プロジェクトテンプレート:Blazor Web App
フレームワーク:.NET 8.0
Interactive render mode:Auto
Interactivity location:Per page/component
※レンダーモードは「InteractiveServerと未指定(SSR)」のみを想定
方法
下記の記事の方法を試したところ成功した
大雑把にまとめると、下記の手順でよい。
①Program.csのapp.UseStaticFiles()の直前に下記を追加
app.UseStatusCodePagesWithRedirects("/statuserror/{0}");
※app.UseStaticFiles()の直前に書く根拠はわからない。
「asp.net core ミドルウェア 順序」あたりで調べたらわかるかも。。
②StatusError.razorを追加
@page "/statuserror/{Status}"
<h3>エラーが発生しました</h3>
<h3>ステータスコード:@Status</h3>
@code {
[Parameter]
public string Status { get; set; }
}
懸念事項
最大の懸念は404以外のステータスでも、StatusError.razorに遷移してしまうことだと思う。
具体的にどういう状況で、404以外のステータスが発生し、かつ、StatusError.razorに遷移するのか、
既存のエラーハンドリングの挙動が変わることはあるのかが気になる。
404ページを設定した後に、「@rendermode InteractiveServer」の画面でボタンをクリック処理で例外をスローした場合、画面下にMainLayoutの「id="blazor-error-ui"」の内容が表示された。これは問題なさそう。
もう1つの懸念は、SSRの画面でフォームを送信した場合だ。(この方法はログイン画面でのみ使用する)
ソース上はrazorファイル上のメソッドが呼ばれているように見えるが、実際は、Razorファイル上のメソッドに対応するPOSTのAPIが自動作成されている。このメソッドで例外が発生した場合はどうなるのだろうか?
このメソッドがで例外が発生したときにMainLayoutの「id="blazor-error-ui"」の内容が表示されないので、自分のPJでは、このメソッド内はすべてtry-catchで囲っいて、例外発生時にエラー画面に遷移するようにしている。そう考えると問題なさそう。
プロジェクトにAPIを追加して、そのAPIが500とか401とかを返却した場合に困りそうな気はする。そもそも、自分のPJの構成ではAPIを使用しないので、気にしなくてよさそう。
あとは、未承認のときに存在する画面に遷移しようとして、未承認のとき用の画面表示が優先されるのか、StatusError.razorへの遷移が優先されるのかは検証が必要だと思う。
それと、試しに存在しない静的ファイルにアクセスしたら、StatusError.razorが返却された。まあ、それはそうだ。そしてHTTPステータスコードは302(リダイレクト)になっていた。まあ、困りはしないかな。。調査の時に302になってるのを見て、あ、これは存在しないページ(ファイル)にアクセスしようとして、リダイレクトされたんだなって気が付きにくいのが懸念ではあるかも?
ほかにも見落としがいくらでもありそう。
そして、ここまでの内容で、周りを納得させることができるだろうか。。
参考