このブラウザーはサポートされなくなりました。
Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(9.6, 28.000000000000004%, 10%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EKN%3C/text%3E%3C/svg%3E)
.Net8のBlazor Web Appプロジェクトの作成し、Interactivity locationがServerの設定プロジェクトで
クライアント側のブラウザで動作、ページ間で共有可能なサービスを保持する手段が知りたい。
.Net8のBlazorではページやコンポーネント単位でWebAssembly側、Server側を指定出来る認識ですが、下記のようなコードの場合、クライアントのブラウザ側で動作するサービスとして、実装する手段はないのか教えて欲しいです。
１つのサービスのみであり、他機能はすべてサーバサイドレンダリングで問題ないため、なんとか簡単な実装でクライアントサイドでリソース、状態取得を出来るようにしたいです。
Program.cs
Counter.razor
ClientSideSingletonService.cs
Blazor Web App はよく分かってないので、的外れなことを言っていたらすみません。
Blazor web appのプロジェクトでInteractive ModeをServerに設定した状態で一部のサービスだけ、クライアント側のシングルトンサービスとすることは可能でしょうか？
現状では、Program.cs の AddSingleton で DI コンテナに登録したサービス (もちろんこれはサーバー側で動く) に、クライアント側からは SignalR を使ってアクセスして利用しているように見えますがどうでしょう？ そうだとすると、現状では期待通り動いているのでしょうか？
そして、やりたいことは、クライアント ⇔ サーバー間の SignalR によるやり取りは止めて、クライアント側単独で処理したいということでしょうか？
回答ありがとうございます。
ご推察の通り、あくまでクライアント側はSignalRでサーバが保持している情報をもらっている形であり、サーバ側のメモリを使ってしまっているので、やりたいクライアント側のサービスかつメモリ消費にすることができていないです。
クライアント ⇔ サーバー間の SignalR によるやり取りをすべてやめるというより、
その一部の機能のみ、サーバ側リソースを使うのではなく、クライアント側で処理するということを実現したいと思っています。
画面描画等はSignalRで勝手にやり取りしてくれていればいいので、あくまで提示させていただいたクラスに関して、クライアント側のサービスかつメモリを使ってくれたらと思っています。
何か考え違いをしていませんか？ 「サーバが保持している情報」というのがどういうものか分かりませんが、サーバーにしかない情報でそれがクライアント側で必要であれば、クライアントからサーバーに要求を出して情報を入手するほかありません。
AddSingleton で DI コンテナに登録したサービスは、先にも書きましたが、サーバー側で動いてます。「Interactive ModeをServerに設定」すればクライアント側で動くということはありません。
どういうことかというと、一度 DI されると、アプリケーションが終了するまで、最初の DI で生成されたインスタンスを使いまわすということです。もちろんサーバー側ででの話です。
ASP.NET アプリはクライアントから要求を受けるたびにスレッドプールからスレッドを取得し、処理に必要なアセンブリをメモリにロードし、処理が完了してクライアントに応答を返すとメモリをクリアし、使ったスレッドをプールに戻すマルチスレッドアプリです。
AddSingleton を選んだ場合、ワーカープロセスが立ち上がった後の最初の DI でインスタンスが生成されると、ワーカープロセスがリサイクルされるまで、すべての要求に同じインスタンスが使い回されるということになります。初期化するのに時間がかかるとかメモリなどリソースを大量に消費するクラスを DI する場合には AddSingleton の利用を考えるのがよさそう・・・ということです。
失礼ながら、XY 問題のような気がします。
XY 問題とは、質問者さんに X という課題があって、質問者さんが Y という解決策を考えついて Y について質問したが（質問には X は書かないで）、Y は X の解決策とはなっておらず、いくら議論しても一向に解決にならないということです。
X も書いていただければ、Y は不可能なのでできないが、X は別の手段で実現できるというような回答が出てくるかもしれません。
AddSingleton で DI コンテナに登録したサービスは、先にも書きましたが、サーバー側で動いてます
上記については、把握しており、AddSingletonを使いたいというわけではないです。
現状、上記のような形でサーバ側で動いているサービスを、どういう手段かでブラウザ側で状態管理させて、ブラウザ側のメモリを消費して動くサービスにしたく、ClientSideSingletonClassのサービスだけサーバの関与しない、ブラウザ側で動くようにしたいという要望です。
類似記述なのか別手段なのかで、Blazorの記述範囲でWebアプリ内のページ遷移に依存しないブラウザ側で動作するバックグランドのサービスにしたいと思っています。
JavaScriptで頑張ればやろうと思えばやれるとは思いますが・・・。
また、InteractiveMode:WebAssemblyにすればサーバとは切り離したクライアントのサービスとして動かすようにできるというのもなんとなく認識はしていますが、上記のクラスだけのために、WebAssembly化したいわけでもないこと、
Blazor web app(.Net8以降)はページやコンポーネント単位で、クライアント側なのかサーバ側なのかを切り離せるような記述もあり、ハイブリッドのようなことが可能になったのでは？という背景もあり、なにかしらの簡易な手段で、上記のClientSideSingletonClassだけをクライアントのブラウザ側で動かしたいと考えていますが、その具体的な手段がわからないための質問になります。
重複したので削除しました
現状、上記のような形でサーバ側で動いているサービスを、どういう手段かでブラウザ側で状態管理させて、ブラウザ側のメモリを消費して動くサービスにしたく、ClientSideSingletonClassのサービスだけサーバの関与しない、ブラウザ側で動くようにしたいという要望です。
それはできません。特に「クライアント側のブラウザで動作、ページ間で共有可能なサービス」というのは逆立ちしても不可能でしょう。
ページ間というのはブラウザでのWebアプリ内のページ間ではありますが、コンポーネントのライフサイクル的にも、実現しようとするとwebassemblyでクライアントとサーバを切り離すか、javascriptを使うという手段になりますか？
.net8以降のページ/コンポーネント単位での指定について知見はありますか？
ページ間というのはブラウザ内の遷移ページ間ではありますが、
サーバーにしか存在しないリソースを利用しないと実現できない話だと思っていましたが、誤解していたかもしれません。
そうではなくて、例えば Home から Counter に遷移する際、Home で作成したデータを Counter でも使いたい・・・要するに状態 (ユーザーデータ ) 管理の話で、Blazor Server を使うと SignalR を使ってクライアントとサーバーのやり取りを行って自動的に状態管理を行うが、そこをサーバーがに関与しないようにしたい・・・という話なのでしょうか？
自分が知る限りですが、状態管理において Blazor Server でサーバーの関与をコントロールする方法はなさそうです。Microsoft のドキュメントでも状態管理は Blazor WASM について書かれたものしか見つかりません。
実現しようとするとwebassemblyでクライアントとサーバを切り離すか、javascriptを使うという手段になりますか？
サーバーが関与しないように状態管理を行いたい、例えば Home から Counter に遷移する際 Home で作成したデータをブラウザーのストレージ (localStorage または sessionStorage) を使って Counter に渡したいということであれば、そういうことになると思います。
関与しないようにしたい・・・という話
例も交えて丁寧に回答いただき、ありがとうございます。認識合っています。
サーバが関与せず、例えば、ブラウザ側でブラウザストレージに貯めた情報を基に、別サーバに定期的にファイルをアップロードし続けるサービスを動かし続けたい等の実現方法についての相談になります。
分かる範囲でも回答いただけて助かります。
手段はないものかと一人で悩んでいたところに、１つの回答をいただけただけでもありがたいです。
やはりそうですよね、私も調べた限りだと上記のような一時ストレージを使いつつ、動作し続けるようなバックグランドサービスを動かしたいのであれば、情報部分はブラウザの一時ストレージで、動作部分はJavaScriptに動き続けてもらうくらいしか思いつかなかったところです。
具体的には、例えば、Home画面でブラウザからサーバにアップロードしたい複数ファイルを選択し、アップロードボタンを押下後、Counter画面に遷移してもアップロードを継続し続けたいというところを実現しようと考えていました。
Interactive ModeがServerモードでは、順次アップロードをし続けていてもページ遷移に伴ってコンポーネントに関する情報が失われることで、ファイルを跨いだあたりでアップロードに使うストリーム情報が取れなくなっていたため、なにかブラウザ側でページ遷移しても情報を保持し、動作し続けるサービスを作る手段はないものかと悩んでいたところでした。
現時点だと、Interactive ModeをServerにしつつ、上記のようなことを実現するには、セッションストレージとかにファイルのパス情報だけ格納して、ストレージ内の情報を定期監視してファイルパスが入っていたら、APIを呼び出してアップロードをしてくれるようなJavaScriptを裏で走らせるしかないのか？とも思っています。
.net8でからページ単位やコンポーネント単位？のrendermodeの切り替え等が可能というような記述もあったので、なにかしら、今回のようなケースにもJavaScriptやブラウザストレージを使わずとも、ブラウザ側のみのサービスを手軽に動作、ページ遷移間で共有できる手段も出来たのか？とも思ったのですが・・・。
すでに検討済み・対策済みで余計なお世話かもしれませんが・・・
Interactive ModeをServerにしつつ、上記のようなことを実現するには、セッションストレージとかにファイルのパス情報だけ格納して、ストレージ内の情報を定期監視してファイルパスが入っていたら、APIを呼び出してアップロードをしてくれるようなJavaScriptを裏で走らせるしかないのか？とも思っています。
ファイルのパス情報をもらっても JavaScript ではアップロードできないと思います。
ブラウザからファイルをアップロードするには、以下の様な <input type="file" name="file" /> を使った html コードでユーザーがファイルを選択するという操作が必要になるはずです。
その後以下の様な JavaScript を使って FormData を取得してユーザーが選択したファイルを送信できますが、別のページでアップロードを行うということになると、下のコード例で言うと let fd = new FormData(document.getElementById("form1")); で取得した fd を別ページに渡せるかが問題になると思います。それは sessionStorage ではできないような気がしますが、いかがですか？
<form id="form1" method="post" enctype="multipart/form-data">
<input type="file" name="file" />
</form>
<button type="button" id="button1" class="btn btn-primary">
アップロード
</button>
<div id="result1"></div>
<script type="text/javascript">
let resultDiv, uploadButton;
window.addEventListener('DOMContentLoaded', () => {
uploadButton = document.getElementById("button1");
resultDiv = document.getElementById("result1");
uploadButton.addEventListener('click', uploadFile);
});
const uploadFile = async () => {
let fd = new FormData(document.getElementById("form1"));
const param = {
method: "POST",
body: fd
}
const response = await fetch("/api/FileUpload", param);
if (response.ok) {
const message = await response.text();
resultDiv.innerText = message;
} else {
resultDiv.innerText = "アップロード失敗";
}
};
</script>
SPA なので上の form 周りの DOM は別ページでも書き換えないということができれば、別ページで上のようなスクリプトでアップロードできるかもしれませんが (未検証・未確認です)、その場合はセッションストレージによる状態管理の話ではなくなってくると思います。
削除しました
アドバイスありがとうございます。
実現しようとしていることに対する、懸念および気になる点についても考察いただけて助かります。
BlazorだとIBrowserFileのところですね。
おっしゃる通り、ユーザの選択操作が必要である(この入口のユーザ操作はまぁよいのですが)ことはその通りで、また、そのままの形だとページ遷移のコンポーネントの破棄とかで選択したファイルからストリーム情報が取得できなくなりますね。
IBrowserfileを使用して非同期にファイル数分のループ処理していると、ページ遷移以降にIBrowserFileからストリーム情報が取得できなくなっていたので、アドバイスいただいたとおり、そのままだとjavascriptでも同様なのかなと思っています。
そのため、ファイル選択した直後のBlazorコードおよびjavascriptのところで、せめてストリームデータとしてブラウザ側でストリーム化してjavascriptの保持領域に受け渡すまで、ページ遷移させないようにして、あとの処理以降は裏で走らせられないかと考えてます。
javascript側で配列保持のような形で、提示いただいたコードでいうところのfd配列群のような形で、変数保持しておけないですかね？
(結局、JavaScriptもページ内部品のようなもので、ページ遷移すると変数情報も消えてしまいますか？JavaScriptのグローバル変数やwindowオブジェクトあたりに保持してBlazor側のページ遷移に耐えて処理継続できないですかね？)
javascript内での変数保持およびsessionstrageが厳しそう(容量が少ないのもあるからですかね？)であれば、最後の頼みの綱はIndexedDBあたりを使えば(使ったことないですが・・・)実現できないかと思案しているところです。
Blazorでやるとしたら、IBrowserFileのFileList変数をストリーム化してJavaScriptに受け渡しのようなイメージ、ここまでの間はページ遷移をさせないようにする等。
こういう背景もあるから、ページ遷移中のバックグランド作業を実現するにあたっては、WebAssemblyのような完全なクライアントアプリとなる存在がありがたいんですかね？
ファイルアップロード以外はサーバとブラウザのSignalR同期で事足りる機能ばかりで、Interactive ModeがServerのケースは基本的にAPIでのやり取り等がなくともいい感じに同期とって反映できるのもあり、コードも書きやすいのですが、ファイルアップロード等、時間のかかる作業をページ遷移後も継続させようと思うと、途端に完全にサーバとクライアントを切り離すかどうかの判断を迫られるのかと、ここの機能だけでいいのにと・・・。
BlazorだとIBrowserFileのところですね。
new FormData(document.getElementById("form1")) のことを言っているのだと思いますが、それは IBrowserFile には該当しません。
上の私のコメントのサンプルコードには IBrowserFile に該当するものはありません。
（ちなみに、IBrowserFile に該当する JavaScript のオブジェクトは、<input type="file" name="file" /> でファイル選択後、その files プロパティで取得できる FileList の個々の要素 File になります）
何にせよ、JavaScript でファイルアップロードするには、上の私のコメントのサンプルコードのようにする他手段はないと思います。（input type="submit" ボタンを form 要素内に配置して、それをクリックするというのは NG です。ファイルはアップロードされますが、返ってきた応答でブラウザの画面が書き換えられてしまうので）
なので、Home でユーザーが選択したファイルを Counter に遷移してからアップロードするには、先に書いた通り、Home で new FormData(document.getElementById("form1")) で取得した FormData を Counter に渡せるかが問題で、それは sessionStorage ではできないし、他のいかなる状態管理の手段でもできないと思います。
ただ、先にも書きましたが、SPA なので上の form 周りの DOM は別ページでも書き換えないということができれば、別ページで上のようなスクリプトでアップロードできるかもしれません(未検証・未確認です)。
でも、その場合は、
Blazor web appのプロジェクトでInteractive ModeをServerに設定した状態で一部のサービスだけ、クライアント側のシングルトンサービスとすることは可能でしょうか？
という話ではもちろんないし、ブラウザのストレージによる状態管理の話でもありません。（だから最初から X を書くようにお願いしたのです）
削除しました
もう一つ、思い違いがあるようなので書いておきます。
IBrowserfileを使用して非同期にファイル数分のループ処理していると、ページ遷移以降にIBrowserFileからストリーム情報が取得できなくなっていたので、アドバイスいただいたとおり、そのままだとjavascriptでも同様なのかなと思っています。
SignalR がどのように介在しているか分からないので Blazor Server での事情は分かりませんが、JavaScript を使った上の例の場合は事情は違います。
上のサンプルコード <input type="file" name="file" /> に multiple="multiple" 属性を追加すれば複数のファイル選択して送信できますが、その際、選択された複数のファイルが一度に multipart/form-data 形式 (form 要素の enctype 属性で指定されている) でサーバーに送信されます。
具体例は以下の Fiddler による要求のキャプチャ画像を見てください。textfile.txt, textfile2.txt, textfile3.txt という 3 つのテキストファイルを選択して送信した結果ですが、画像に示されている通り 3 つのファイルが一度に multipart/form-data 形式で送信されています。
この後はサーバー側の Web アプリの仕事になり、クライアント側は関係なくなります。
Web アプリにファイルを受信して処理するアクションメソッドを実装しフォームデータを受信して、それからファイルのデータを取得し、必要な処理を行うということになります。
一旦アクションメソッドが要求を受けて処理を始めてしまえば処理が終わるまで実行されます。クライアント側のブラウザでページ遷移しても影響はありません。
重複したので削除しました
質問者さん、無言になってしまいましたが、2024年10月30日 18:45 と 2024年10月31日 10:35 の私のレスに対するフィードバックを書いていただけませんか？
FormData を Counter に渡せるかが問題で、それは sessionStorage ではできないし、他のいかなる状態管理の手段でもできないと思います。 SignalR がどのように介在しているか分からないので Blazor Server での事情は分かりません
上記のあたりについて、Blazor ServerとJavaScriptの呼出しによる試し実装していたため、時間がかかってしまい回答が遅くなりすみません。結果からの回答になりますが、BlazorからJSRuntimeによるJavaScript関数の呼出しをした上で、HomeからCounter等のページ遷移後、BlazorからJavaScriptに渡したbyteデータ保持が思ったメモリ消費でブラウザ側に保持される動きを確認できました。App.Razorファイル、ここに共有したいwindowオブジェクトのbyte配列を定義した.jsファイルを設定。
(ここでの定義で画面には表れないが、ページ間でオブジェクト共有できるところの理由か？)
そのうえで、各画面で下記定義と、.jsファイルのwindowオブジェクトのbyte配列に格納する関数、取得する関数を呼び出すところを実装することで、別ページでjavascriptのwindowオブジェクトに格納したデータについても保持取得できる状態にはなりそうです。
"@inject IJSRuntime JSRuntime"
まだ送信のバックグラウンドをjavascriptで実現してはいないですが、とりあえず、ブラウザ管理のwindowオブジェクトとして、byte配列データをページ遷移にも耐えるとこまでは、やりたいことを想定通りに実現できました。
App.Razorファイル、ここに共有したいwindowオブジェクトのbyte配列を定義した.jsファイルを設定。
それは先に私のレスで書きました、
SPA なので上の form 周りの DOM は別ページでも書き換えないということができれば、別ページで上のようなスクリプトでアップロードできるかもしれません(未検証・未確認です)。
・・・と同様な話で、「form 周りの DOM は別ページでも書き換えない」というところを、<input type="file" name="file" /> でファイル選択後、その files プロパティで取得できる FileList の個々の要素 File を App.Razor の変数として保持しておけば、そこはページ遷移で書き変わることはないので、どのページからも使えるという話でしょうか？
それでできるのか確認してみますので、その理解であっているかどうか返答願います。
SPA なので上の form 周りの DOM は別ページでも書き換えないということができれば、別ページで上のようなスクリプトでアップロードできるかもしれません(未検証・未確認です)。
上記のままでは、Blazor Serverで具体的にどうコードを書けば実現できるのか答えにたどり着けないので、具体的な結果をせめて残したかったというのもあります。
ページ遷移で書き変わることはないので、どのページからも使えるという話でしょうか？
その認識で合ってます。
Blazor ServerでのApp.razorのRouteエリアに対するjavascriptの追加に関しては、上手い具体にブラウザ側の共有データとして保持出来たことを確認出来た感じです。
もう一つ確認させてください。
そもそもの問題・課題は「複数のファイルをアップロードすると、どこかで失われて失敗するケースがある。そこを解決したい」ということですよね？
であれば、それは 2024年10月31日 10:35 の私のレスの通りにすれば解決できるはずです。
私のレスに書いた、複数のファイルが一度に multipart/form-data 形式で送信されているところは見てもらえましたか？
この後はサーバー側の Web アプリの仕事になり、クライアント側は関係なくなりますと書いたことは理解してもらえましたか？
なので、上の問題・課題を解決するために、
App.Razorファイル、ここに共有したいwindowオブジェクトのbyte配列を定義した.jsファイルを設定。
というようなことを考える必要はないはずです。
違いますか？
なぜ 2024年10月31日 10:35 の私のレスの通りにしてはダメなのか教えてください。
App.Razorファイル、ここに共有したいwindowオブジェクトのbyte配列を定義した.jsファイルを設定。
私が当初この質問で定義した形のように、情報を保持、送信できるのであれば、クライアント側のブラウザで調整できることが広がるかとは思います。
Javascript無しにBlazor Serverだけでも、ただ、複数ファイルを非同期に送るだけなら、非同期に複数ファイルを開いて、CopyToAsyncさえ走り始めてしまえば、送信中でもページ遷移に耐えれそうなことは挙動からではありますが、確認してあります。
Blazor Serverプロジェクトで送るタイミングも調整しつつ、遷移にも耐えつつ、サーバ負荷を調整するようなWebAssemblyのような位置づけでデータを送ることも出来るようにしたいため、敢えて、質問した形のようにクライアント側での部品単位にレンダリングモード指定する等、基本的にはBlazor Serverプロジェクトであることを維持しつつ、データと制御をブラウザ側の処理に託した形にしたかったというところがあります。
BlazorServerプロジェクトで、WebAssemblyのように情報を保持、制御することを、当初はBlazorのみのコード記述範囲で実現する手段を知りたいというところではあったんですね。
ファイルのアップロードもやりたいことの一例ではありますが、
情報保持およびデータ制御をブラウザ側に託すことが出来るのであれば、Blazor Serverプロジェクトでありながら、一部だけWebAssemblyのような形を実現し、
Blazor Serverの作りの手軽さとWebAssemblyのデータと制御のブラウザ側への切り離しを実現できる手段を知りたいなと思ったところが質問の背景になります。
そういった背景もあり、.net8のWeb Appというところでは、このあたりのハイブリッド指定がどうのという変化もあり、いい感じに上記のことを実現できる手段がBlazorに出来たのではと思いつつも、このあたりの新機能を使った実現手段を知らないため、質問させていただきました。
具体性がなくて何をしたいのかさっぱり分かりません。
何にせよ、
そもそもの問題・課題は「複数のファイルをアップロードすると、どこかで失われて失敗するケースがある。そこを解決したい」ということですよね？
に対する答えは No ということで、私の想像の範囲をはるかに超えたことをやりたいのであろうという気がしてます。今まで話して来たファイルアップロードの件は、その想像を超えたところでできることの一つに過ぎないようですね。
今まで話してきたファイルアップロードの件のような具体的な話にしてもらえない限り、これ以上話しても発散するばかりと思いますので、そうしてもらえないのであれば自分はこのスレッドからは撤退します。
そもそもBlazor web appを扱ったことない中で答えていただいているでしょうから、知ってる知識だけでも十分ありがたいですよ。
ファイルアップロードの件は、その想像を超えたところでできることの一つに過ぎない
そうなります。
もともとは、サーバとクライアントを切り離して実現している大規模アプリをサーバサイドレンダリング主体のBlazorサーバで実現していけるのかどうか、実現したい機能の全てを挙げていくと際限なく膨れ上がっていきそうなので、あくまでデータと制御の切り離しをBlazor Serverプロジェクトだけれど、必要に応じてクライアント側のブラウザで実現できるようにするにはどうすればいいか？という点で聞いた方がいいかと思い、質問させていただく中で、一例としてファイルアップロードを挙げたというところはあります。
元々が実現不可能な、
Blazor web appのプロジェクトでInteractive ModeをServerに設定した状態で一部のサービスだけ、クライアント側のシングルトンサービスとすることは可能でしょうか？
というところから始まって、その延長線上でいろいろ考えておられるようですが、具体性が何もないところでこれ以上話しても有用な提案など出てくるはずはなく、発散するばかりと思いますので、自分はこのスレッドからは撤退します。悪しからず了解ください
サーバ側で動作する共有サービスの言い回しになるような、シングルトンサービスという言葉が適切ではなかったですね。
シングルトンパターンを持った機能クラスをブラウザ側でページ間共有で保持する手段はあるか？等の言い回しの方が適切な質問になったかもしれないです。
長々お付き合いいただき、ありがとうございます。
上記については、やり取りしていく中でルート定義のJavaScriptの依存注入で、とりあえずは、InteractiveModeをServerに設定した状態で、目的通り、一部だけをブラウザ側のページ間共通のサービス化は出来そうところには落ち着いてはいるので、まだなんとかやりたいことがBlazorでもやれないことはないことを知れました。
ただ、まだ上記のことをBlazorの.razor周りのみの記述範囲で実現することは出来ていないのも確かで、新機能含めたBlazorに対する理解がまだ足りてないだけではないかとも思うので、また別の形で質問してみます。
また、私自身が今回の質問をキッカケに、BlazorもJavaScriptも触り始めたばかりというところもあるため、触っていく中で分かることが出てきたらここにも追記してみます。
ありがとうございました。