スイッチブレイザーのインタラクティブ

既存のPower Portals Proプロジェクトをあるインタラクティブモードから別のモードに切り替えるには、 Program.cs、 App.razor、 .Client プロジェクト、そして(インタラクティブ性を追加する際は)アカウントページの一連の編集が必要です。フレームワーク自体は変更を必要としず、ホスト配線だけが変更を必要とします。以下のステップでは、一般的な移行について説明します。

ヒント

カスタマイズがページ数が限られているなら、最も手間が少ないのはターゲットモードで新しいプロジェクトを足場に組み込み、カスタマイズをコピーすることです。手動切り替え後に不一致を追跡する際にも、現在のホストと新たに生成された参照を比較するのが有効です。

WebAssemblyまたはAuto→サーバー

これらのステップにより、WebAssemblyはサーバー専用ホストに追加されます。WebAssembly専用でもAutoでも同じ編集が適用されます。違いは Program.cs でどのビルダーメソッドを連結するかと、 App.razor がどのレンダリングモードを返すかだけです。どちらもステップごとに指示されます。

1. を変換する。WebAssemblyアプリへのクライアントプロジェクト

.Client/MyApp.Client.csprojを開き、SDKをMicrosoft.NET.Sdk.RazorからMicrosoft.NET.Sdk.BlazorWebAssemblyに変更してください。WebAssemblyフレームワークとPower Portals Proクライアントパッケージを追加してください:

WebAssemblyのサーバーサイドホスティングパッケージもサーバーホストの.csprojに加えましょう。WASMバンドルを提供するミドルウェアを提供します。

2. サーバー上でインタラクティブなWebAssemblyコンポーネントを登録する

サーバー Program.csでは、コンポーネント登録を対応するビルダーコールに置き換えます。 AddAuthenticationStateSerialization() 認証済みユーザーをServer→WASM境界を越えてシリアライズし、両方のランタイムでカスケード AuthenticationState が一貫性を保つようにします:

3. WebAssemblyのレンダリングモードをマッピングする

app.MapRazorComponents<App>()を更新して、対応するレンダーモードエンドポイントをチェーン化します。AddAdditionalAssemblies呼び出しはすでにテンプレート内の.Clientアセンブリの_Importsを指しているため、ここでは変更されません:

4. App.razorのPageRenderModeを更新

App.razorのPageRenderModeゲッターで新しいレンダリングモードを返します。まずInteractiveWebAssemblyRenderMode(prerender: false)にピン/Account/*し、それ以外はデフォルトに戻します:

Account-routeのピンが必要なのは、フレームワークの IAuthService がWASMクライアントのDIグラフにのみ登録されているからです。ピンがなければ、Autoのサーバー側プリレンダーはコールドセッションで [Inject] IAuthService を解決できません。

5. 加算 。クライアント/Program.cs

.ClientプロジェクトでProgram.csを作成します。これによりWebAssemblyホストがセットアップされ、クッキー転送ハンドラでHttpClientを登録します(WASMクライアントからの認証呼び出し/api/*ブラウザと同じ認証クッキーを認識し)、WASM側フレームワークサービスを登録するためにAddPowerPortalsProWebClient呼び出しを行います。UserPowerPortalsProWebClient呼び出しは起動時にクロスカッティングローカリゼーション文字列をプリフェッチし、最初のペイント時にキーがフォールバックテキストとして点滅しないようにします:

6. フォームポストからJSON認証エンドポイントへの切り替え

サーバーホストはフォームポストのアイデンティティページに MapAdditionalIdentityEndpoints() を使用します。WebAssemblyやAutoホストは代わりに MapAuthEndpoints<TUser>() を使用します。 .Clientの IAuthService ラッパーはこれらのJSONエンドポイントを /api/auth/*以下で呼び出します。

ホストがサーバーアカウントページとWASMアカウントの両方を実行している場合(一般的ではありません)、両方のエンドポイント登録が共存します。デフォルトのテンプレートは、インタラクティブモードに応じてどちらか一方を選択します。

7. アカウントページをクライアントプロジェクト

Power Portals Proは、それぞれのレンダリングコンテキストごとに2つの並列したアカウントページセットを出荷しています:

8. オプション — /api/* 用のスコープ付き例外ハンドラ

WebAssemblyが稼働中の場合、/api/*からの例外はRFC 9457 problem+jsonとしてWASMクライアントに往復送され、クライアント側PowerPortalsProService元のCLRタイプをリハイドレートできます。テンプレートはこれにスコープ付き/api/*UseExceptionHandlerを割り当てていて、他の部分では開発者例外ページがサーバーレンダリングされたエラーを処理します。

WebAssemblyまたはAuto → Server

上記の手順を逆にします:

オート↔ウェブアセンブリ

最も安価な切り替えは、プロジェクトのレイアウト、パッケージ、アカウントページが両者で同一です。変わるのは三つだけです。

スイッチの検証

変更後:

注記

サーバーとWASMクライアント間でサービスを移動する際のサービス寿命の不一致に注意してください。WASMホストはセッションごとに単一のスコープとして動作しますが、フレームワークのキャッシュサービスはシングルトンとして登録されます。WASM側で自分のサービスを Transient として登録すると、インスタンスごとにすべてのリゾルブが静かにリセットされます。可変状態を持つサービスにはWASM側の Singleton を使いましょう。