数ヶ月前からBlazor WebAssemblyだったり、Native Dependenciesについて色々調査したりしてました。
最近はその技術の延長線としての .NET WebAssembly without Blazor UI と紹介されている技術の調査とバグ報告をしています。
今まではBlazorアプリケーション上に展開したページComponentのメソッドをJavaScript相互運用機能などでJavaScript側に提供したり、またその逆を行ったりしていました。
ASP.NET Core Blazor で .NET メソッドから JavaScript 関数を呼び出す | Microsoft Docs
そのためどうしても使わないにしても空のBlazor UIなどを実装して、Window Globalなどにメソッドを公開するといった手間が発生していました。 その際に行うGlobal空間への公開のデメリットなどを抑えるために、過去にReact.jsやVue.jsのコンポーネントに対して相互運用のObjectを公開して影響範囲を抑える、みたいなことを過去に紹介しています。
Blazor ComponentsをVue.jsから使うためのコードのGeneratorを作った - 窓を作っては壊していた人のブログ
これも結局はBlazor UIのコードを書いていますし、更にGenerator向けのコードを書くみたいな手間が発生しています。
これの問題の一部を解消するのが今調査している .NET WebAssembly without Blazor UI 技術です。
詳しいことはC100で頒布予定の技術書に記載するので省略しますが、ものとしては
runtime/src/mono/wasm at main · dotnet/runtime · GitHub
で開発されている技術です。
ここ2ヶ月で大幅に作りが変わり、現在リリースされているPreview 6とmainでも大きく使い勝手が変わっていて追うのが大変ではありますが、非常に見応えのあるものとなっています（この記事の更新中に約1ヶ月開発が行われていた大規模リファクタリングがmergeされました）。
大きな差分を紹介すると
- デフォルトのモジュールシステムがCSJからESMに変更
- JS相互運用のためのアノテーションの追加(JSImport, JSExport)
あたりでしょうか。
1つ目の変更は影響ある人は今の所多くない…とは思うのですが、2つ目は非常に使い勝手の良くなる変更です。 例えばStatic Methodを実行する時、以前の実装では
BINDING.bind_static_method(
"[console] Sample.HttpTrigger:ResponseMessageTemplate"
);
の様に [$assemblyName] $Namespace.$ClassName:$StaticMethodName みたいな形式で呼び出さなければ行けなかったのですが、
今では
exports.MyClass.Greeting();
みたいに exports 変数に全てBindするみたいなことが可能になり、.NETのコード呼び出しのためのコーディングコストが大幅に減りました。
みたいに面白い技術があるけれども、あまり知られていない、試し方が知られていないなというのを感じたのでC100で.NET WebAssemblyについての記事を頒布する予定です。
土曜日 西地区 "す" ブロック 17a
でぜひお手にとってみてください。
