についてのエピソードと感想記事。
チューニングしたい人はドキュメントにそういうページがあるのでその通りにすればよい。 僕もそうした。
背景
Blazor WebAssemblyはWebアプリケーションのクライアントサイドレンダリングフレームワークの一種で、当然ながらUIの応答速度は速ければ速いほどほどいい。
JavaScriptの類似フレームワークでは仮想的なDOMを構築して、前回レンダリングした時との差分だけレンダリングすることで速度を稼ぐのが主流だったろうか。
これに対してBlazorのレンダリングはコンポーネント単位で、あるコンポーネントで何かが起きるとそのコンポーネント全体が再レンダリングされる。子コンポーネントがある場合、既定では全ての子孫コンポーネントが再レンダリングされる*1。
Blazorは純粋なクライアントサイドレンダリングフレームワークではなく、サーバサイドレンダリング（Blazor Server）もできる*2から互換性*3がとりやすい単位でのレンダリングを行う形を取っているようだ。
何も考えないと厳しい応答速度
あるコンポーネントで何かが起きると
これの一つがイベントハンドリングで、コンポーネント上のイベントを何かしらハンドリングするとそのコンポーネントが再レンダリングされる。
直近で作っていたアプリでは以下のようにタブを切り替えたり、アンカーリンクしたりしていた。タブ切り替えもスタイルシートで可視性を変更しているだけだし、アンカーリンクに至っては見た目は何も変更していない。
が、これらはBlazorコンポーネントのイベントをハンドリングしているので、処理中で見た目に影響のある操作をしていなくてもコンポーネントが再レンダリングされる。
添付したGIFアニメは再レンダリングを抑制した*4後のものなのでキビキビ動いているが、抑制前はクリック毎にワンテンポ待たされていた。無策だと大き目のデータを表示するページの操作に対する応答速度は厳しそうだった。
好みとか
何も考えないでいると厳しそうだったけれど、コンポーネント単位でのレンダリング制御はしやすくて好みだった。
コンポーネント志向の感じが少し触っていたことのあるASP.NET Web Formsと似てるのもすんなり受け入れられているのかもしれない。特にBlazor Serverの振る舞いはASP.NET AJAX Controlと感覚が近い。
非常に丁寧なWeb Formsからの移行案内ドキュメントもあって移行案件獲得していくぞ！ な気合を感じる。
とはいえ、日本で本気で展開するなら要所のドキュメントはちゃんと日本語翻訳したほうがいいと思う。
機械翻訳はGoogle翻訳のほうがまだ読みやすいので無いほうがマシ。僕は英語記事をGoogle翻訳して読んでいる。そのほうが原語も見やすい。
特にオチはないけれどそんな感じ。Blazorは良いものだ。
*1:細かい話はこの辺に書いてある https://docs.microsoft.com/en-us/aspnet/core/blazor/components/rendering?view=aspnetcore-5.0#conventions-for-componentbase
*2:Blazor Serverではコンポーネントで何かが起きるとサーバーにそのイベントを送って結果としてレンダリング結果を受け取る
*3:BlazorのコンポーネントはWebAssemblyとServerで互換性がある
*4:https://github.com/7474/SRC/pull/38/commits/4db2cd356f4d8004e5484af2167e9ac36078e835#diff-4b8280b8107e131f2b3631bdc66c984d5621ab392dd39a138a3aa5b66b692fb9R34-R43
