Blazor状態管理: 考慮すべきベスト プラクティス

私たちが話すときBlazor、状態は、ユーザーの操作を含むフレームワークを使用して構築するアプリの重要な部分です。ユーザーが機密データを表示するためにログインする必要があるシナリオを考えてみましょう。ただし、状態が適切に管理されていないため、ページを再読み込みするたびに何度もログインする必要があります。今後もアプリケーションを使い続ける可能性はどのくらいありますか?あまり可能性は低いと思います。

このような UI の応答性の低下やユーザー エクスペリエンスの低下を回避するには、開発者は効果的かつ適切なBlazor状態管理を実装する必要があります。これにより、アプリの構築に使用されるBlazorコンポーネントは相互に通信し、親コンポーネントから子コンポーネントに特定のデータを効果的に転送できます。

しかし、Blazorのステートマネジメントは具体的にどのように機能するのでしょうか? Blazor WebAssembly アプリとBlazor Server アプリの違いは何ですか?このクイックガイドでは、深く掘り下げます。

Try Ignite UI for Blazor

Blazorアプリでの状態の管理の詳細

では、Blazorにおけるステートマネジメントとはどのようなものなのでしょうか?基本的には、データの処理 + 応答性の高いユーザー インターフェイス (UI) の状態を維持するプロセスを指します。これは、いくつかの理由で非常に重要です。

• これにより、Blazorアプリケーションは、接続が切断されたり失われたりした場合でも、現在の状態を維持できます。
• ユーザー固有のデータを記憶できるようにします。
• UI をデータと同期し、アプリ データの変更は常に反映されます。
• Facilitates communication between Blazor components.
• また、リアルタイムのクライアント側のインタラクティビティの管理にも役立ちます。

プロセスがどのように見えるかを確認したい場合は、この簡略化された視覚化+説明を見てみましょう。

一般に、Blazor状態管理は、ユーザー設定やフォーム入力からグローバル設定やリアルタイム更新に至るまで、アプリデータの体系的な制御と保存として理解できます。コンポーネントはデータを共有するため、パラメーター、カスケード パラメーター、またはサービスを通じてデータを共有しますが、独自のローカル状態を維持することもできます。

場合によっては、適切な状態管理を実行するために、グローバル状態コンテナを実装する必要があります。共有データを管理するための一元化されたリポジトリとして機能する一方で、一貫したアクセスと更新も保証します。しかし、状態の更新をトリガーするものは何でしょうか?これには、ユーザー操作、イベント、または外部の変更が含まれる場合があります。状態の更新がトリガーされると、Blazorコンポーネントがそれらに登録し、変更に従って UI をレンダリングします。

以下は、Blazor状態管理の使用を検討すべき一般的なユースケースです。

• コンポーネント階層に直接関連していない複数のコンポーネント間でデータ交換と相互作用がある場合。
• アプリケーションのさまざまな部分で共有およびアクセスする必要があるデータがあり、ユーザー認証ステータス、承認、ロールなどを追跡する必要がある場合。
• ユーザーの操作やデータの変更などに応じてUIを更新したい場合
• 共有アプリケーション設定または複数のコンポーネントがアクセスする構成の場合。
• データ キャッシュは、データが頻繁に変更されない場合にBlazorアプリのパフォーマンスと応答性を向上させます。
• ページが更新される場合 (たとえば、ページ/アプリにショッピング カート、データ フォームなどがある場合) に、ユーザー固有のデータを保持するため。
• ユーザー固有の設定(ディスプレイ設定、レイアウトの選択肢など)が保存されたパーソナライズされたUXを作成します。
• リアルタイム更新をクライアントとサーバー間で分散する必要がある場合。
• 各ステップがその状態を維持するマルチステップのウィザードスタイルのインターフェイスを作成し、ユーザーが進行状況を維持しながら前後に移動できるようにします。
• また、データ グリッドやリストに適用されるフィルター、並べ替え条件、または検索クエリを管理する場合にも役立ちます。

もちろん、アプリケーションの特定の目的とロジック、およびさまざまな状態管理手法がそれを最も十分に達成するためにどのように役立つかを常に考慮してください。

Blazorで状態管理を使用する方法

Blazor何度も議論し、その仕組みについてはすでに概説してきましたが、簡単にまとめると、このフレームワークでは、純粋なC#スキルと.NETを使用してインタラクティブなWebアプリケーションを構築できます。ここにはJavaScriptはありません。しかし、クライアントとサーバーの相互作用を処理するには 2 つの方法があります – 1 つはBlazor Server を使用する方法、もう 1 つは WebAssembly (WASM) Blazor方法です。Blazor Server では、アプリはサーバー上で実行され、すべての UI 更新は SignalR 接続を介してクライアントにフェッチされます。これにより、実際には、集中制御を備えたリアルタイムアプリケーションに適しています。

一方、Blazor WebAssembly は Web ブラウザーで直接実行されるため、クライアント側での完全な実行が可能になります。これは、アプリがオフラインで動作する必要がある場合や、サーバー インタラクションを最小限に抑えながら、クライアント リソースの消費量が多いシナリオに最適です。

これらのアーキテクチャの違いは、Blazor Server State Management とBlazor WebAssembly State Management にも反映されています。これについてさらに詳しく見てみましょう。

Blazor Server State Management

まず最初に、Blazor Server は SignalR を使用してリアルタイムの状態更新を行うことができます。ただし、一般に、Blazor Server アプリの状態管理は、回路と呼ばれる構造体でメモリに格納されます。これは、接続の問題やネットワーク遅延が長くない限り、リアルタイム更新のフェッチが問題になる可能性があるため、問題ありません。このシナリオでは、Blazor同じ回線への再接続を再試行します。しかし、それが失敗し、遅延が長引くと、新しい回線が確立され、重要なデータが失われる可能性があります。

Blazor WebAssembly State Management

​Blazor WebAssembly アプリでの状態管理に関しては、状態はユーザーが使用するブラウザーでホストされます。状態管理にサーバーメモリに依存しないため、アプリケーションの整合性は、遅延やネットワークとの接続の問題の影響を受けません。ただし、ページを更新するか、アプリケーションを再度開くと、通常は状態がリセットされます。

たとえば、複数ページのフォームを持つBlazorアプリがあり、ローカル ストレージを使用してページ間の状態を保持するとします。これにより、ユーザーは未完成のフォームを送信せずに「戻る」ボタンと「進む」ボタンを使用できます。長い調査フォームのようなものです。

状態管理の例

どちらの場合も、状態永続化の実行について考える必要があります。Microsoftが最初に強調したように、

“…ユーザーが既に存在するデータを読み取るだけでなく、アクティブにデータを作成している回線間で状態を維持します。回路間で状態を保持するには、アプリはデータをサーバーのメモリ以外のストレージ場所に保持する必要があります。状態の永続化は自動的には行われません。アプリを開発するときは、ステートフルなデータ永続性を実装するための手順を実行する必要があります。データの永続性は、通常、ユーザーが作成に労力を費やした価値の高い状態にのみ必要です。

これらは、状態を保持する一般的な場所です。

• Server-side storage (Database)
• クライアント側 (ブラウザー)
• URL
• インメモリ状態コンテナー サービス

また、このアプリは、特に異なるユーザーやデバイス間での永続的なデータ永続性に関しては、サーバー側のストレージに依存することもできます。使用可能なオプションは次のとおりです。

• Blob storage
• Key-value storage
• Relational database
• テーブル ストレージ

データが保存されると、ユーザーの状態は保持され、どの回路からでもアクセスできます。

Blazorアプリケーションの状態管理のためのベストプラクティスとアプローチ

Blazor State Managementとは何か、そしてそれがBlazor WebAssemblyおよびBlazor Serverアプリでどのように機能するかを明確にした後、Infragisticsが探求し、今強調したいベストプラクティスとアプローチのいくつかについて説明しましょう。各アプローチは異なる目的を果たすことに注意してください。したがって、アプローチを選択し、優れたプラクティスに依存するかどうかは、アプリの要件、必要な状態管理の範囲、Blazorアプリ内の複雑さなど、プロジェクトの詳細に常に依存します。

コンポーネントパラメータまたはカスケード値

Blazorでは、パラメーターを使用してコンポーネント間でデータを渡すことができます。コンポーネントには、データを受け入れるパラメーターを含めることができ、これらのパラメーターは親コンポーネントによって設定できます。カスケード パラメーターを使用すると、同じデータをコンポーネント階層 (親コンポーネントから子コンポーネントへ) に渡したり、アプリ コンテキスト全体に CascadingValue をラップしたりすることもできます。

これはいつ使用するのが良いですか?

パラメータの使用は、階層構造の親コンポーネントと子コンポーネント間でデータを共有する場合に便利です。

URLおよびクエリパラメータへの状態の保存

これは、ユーザーが URL を送信することで、アプリケーションとその状態をユーザー間で共有できるようにするため、非常に重要です (クエリ パラメーターとして埋め込まれたフィルター条件など)。

これはいつ使用するのが良いですか?

たとえば、保存した URL をクリックして特定のビューや設定に直接アクセスできるようにする場合や、パーマリンクを作成する場合などです。

フィールドとプロパティによるコンポーネントの状態の維持

Blazorの最も優れた点の 1 つは、各コンポーネントが独自の状態を維持できるため、フィールドとプロパティを使用してコンポーネント内の状態を簡単に管理できることです。これにより、コンポーネントの状態は、定義されている特定のコンポーネントに分離されます。

これはいつ使用するのが良いですか?

これは、他のコンポーネントと共有する必要のないコンポーネント固有のデータがある場合に最適です。

依存関係の挿入とサービスの作成

サービスを作成することで、依存関係の挿入を使用して、すべてのコンポーネントでサービスが使用可能であることを確認する必要があります。このアプローチは、複数のコンポーネント間でアクセス可能である必要があるデータと状態を共有する場合に便利です。

これはいつ使用するのが良いですか?

これは、アプリケーション全体の状態を管理し、さまざまなコンポーネントにデータを提供し、アプリケーションの状態を管理するための一元的な場所を提供する場合に最適な方法です。

サードパーティの状態管理ライブラリからのサポートの利用

Blazor開発者は、Fluxor、Blazor-State、Redux ベースのライブラリなどのサードパーティ ライブラリを使用して、アプリの状態を管理できます。これらは、状態管理に対するより構造化された複雑なソリューションを提供する + Flux アーキテクチャのような確立されたパターンを実装するため、便利です。

これはいつ使用するのが良いですか?

大規模で複雑なBlazorアプリケーションで状態管理を整理および合理化したい場合。

結論として...

効果的な状態管理を行うことは、応答性が高く、保守可能で、ユーザー フレンドリーなBlazorアプリケーションを構築するための中核です。この記事で説明したベスト プラクティスとアプローチを実装することで、プロジェクトがデータを効率的に処理し、コンポーネントの相互作用をシームレスに同期し、より優れた UX を提供できるようにすることができます。ただし、何を選択する場合でも、アプローチが長期的により多くの利益をもたらすように、常にアプリケーションの状態のニーズを考慮してください。