ASP.NET Core Blazor 状態管理

サーバー側 Blazor はステートフル アプリ フレームワークです。 アプリでは、ほとんど常に、サーバーとの接続が維持されています。 ユーザーの状態は、"回線" の中のサーバーのメモリに保持されます。

たとえば、回線には次のようなユーザー状態が保持されます。

• レンダリングされた UI での、コンポーネント インスタンスの階層と最新のレンダリング出力。
• コンポーネント インスタンスに含まれるフィールドとプロパティの値。
• 回線に範囲が設定されている依存関係の挿入 (DI) サービス インスタンスに保存されているデータ。

ユーザー状態は、JavaScript 相互運用の呼び出しによって設定される、ブラウザーのメモリ内の JavaScript 変数にも存在する場合があります。

ユーザーが一時的にネットワークに接続できなくなった場合は、Blazor により、ユーザーを元の状態で元の回線に再接続することが試みられます。 ただし、サーバーのメモリにある元の回線にいつでもユーザーを再接続できるわけではありません。

• サーバーでは、切断された回線を永久に保持することはできません。 サーバーでは、タイムアウト後、あるいはサーバーがメモリ不足になったとき、切断された回線を解放しなければなりません。
• 複数のサーバーが存在する負荷分散された展開環境では、個々のサーバーは、それがなくても全体的な要求量を処理できるようになると、作動しなくなったり、自動的に削除されたりすることがあります。 ユーザーが再接続しようとしたときに、ユーザーの要求を処理していた元のサーバーを使用できなくなることがあります。
• ユーザーはブラウザーを閉じてから再度開くか、ページを再読み込みできます。これにより、ブラウザーのメモリに保存されている状態が削除されます。 たとえば、JavaScript 相互運用の呼び出しによって設定された JavaScript 変数の値は失われます。

ユーザーが元の回線に再接続できないとき、そのユーザーには、状態が空の新しい回線が与えられます。 これはデスクトップ アプリを終了してから再度開くことと同じです。

回線間で状態を維持する

一般に、ユーザーが既存データを単に読み取るのではなく、活発にデータを作成している場合は、回線間で状態を保持します。

回線間で状態を維持するには、アプリで、サーバーのメモリとは異なる他の保存場所に、データを保持する必要があります。 状態は自動的に保存されません。 ステートフルなデータ保存を実装するアプリを開発するとき、措置を講じる必要があります。

データの保持は、通常、作成するためにユーザーが大きな労力を費やした、価値の高い状態の場合にのみ必要です。 次の例では、状態を維持することで、時間が節約され、商業活動の支援になります。

• 複数ステップの Web フォーム: 複数ステップの Web フォームのいくつかのステップを完了した後で、状態が失われた場合、ユーザーがデータを再入力するのでは時間がかかります。 このシナリオでは、フォームからユーザーが離れて後で戻ってきた場合、状態が失われます。
• ショッピング カート: 収益につながる可能性がある、アプリの中のビジネス上重要なコンポーネントを維持できます。 ユーザーが自分の状態を失い、そのため、自分のショッピング カートが消えると、後でサイトに戻ってきたとき、製品やサービスの購入数が減ることがあります。

アプリでは、"アプリの状態" のみが維持されます。 コンポーネント インスタンスやそのレンダー ツリーなど、UI は維持されません。 コンポーネントとレンダー ツリーは一般的にシリアル化されません。 アプリで、ツリー ビュー コントロールの展開されたノードなど、UI の状態を維持するには、カスタム コードを使用して、UI 状態の動作をシリアル化できるアプリ状態としてモデル化する必要があります。

状態を維持する場所

一般に、状態を維持するために、次のような場所があります。

• サーバー側ストレージ
• URL
• ブラウザー ストレージ
• メモリ内状態コンテナー サービス

サーバー側ストレージ

複数のユーザーとデバイスにまたがって永続的にデータを保持する場合は、サーバー側ストレージをアプリで使用できます。 次のオプションがあります。

• BLOB ストレージ
• キーと値のストレージ
• リレーショナル データベース
• テーブル ストレージ

データが保存された後は、ユーザーの状態は保持されていて、新しい回線で使用できます。

Azure のデータ ストレージ オプションの詳細については、以下を参照してください。

• Azure のデータベース
• Azure Storage のドキュメント

URL

ナビゲーションの状態を表わす一時的なデータについては、URL の一部としてデータをモデル化します。 たとえば、次のようなユーザー状態が URL でモデル化されます。

• 表示されるエンティティの ID。
• ページ付きグリッドでの現在のページ番号。

次の場合、ブラウザーのアドレス バーのコンテンツが保持されます。

• ユーザーがページを手動で再読み込みした。
• Web サーバーが利用できなくなり、別のサーバーに接続する目的で、ページの再読み込みがユーザーに強制される。

@page ディレクティブで URL パターンを定義する方法については、「ASP.NET Core の Blazor ルーティングとナビゲーション」をご覧ください。

ブラウザー ストレージ

ユーザーが頻繁に作成する一時的なデータの場合、一般的に使用されるストレージの場所は、ブラウザーの localStorage コレクションと sessionStorage コレクションです。

• localStorage の対象範囲はブラウザーのウィンドウです。 ユーザーがページを再読み込みするか、ブラウザーを閉じてから再度開いた場合、状態は保持されます。 ユーザーが複数のブラウザー タブを開くと、状態はすべてのタブで同じになります。 データは直接消去されるまで localStorage に残ります。
• sessionStorage の対象範囲はブラウザーのタブです。ユーザーがタブを再読み込みすると、状態は維持されます。 ユーザーがタブかブラウザーを閉じると、状態は失われます。 ユーザーが複数のブラウザー タブを開くと、それぞれのタブには、他に依存しないそのタブだけのバージョンのデータが保持されます。

一般に、sessionStorage を使用しておけば安全です。 sessionStorage の場合、ユーザーが複数のタブを開き、以下に遭遇するリスクが回避されます。

• タブ間の状態保存に含まれるバグ。
• タブで他のタブの状態が上書きされるときの紛らわしい動作。

ブラウザーを閉じてから再度開いてもアプリで状態が保持される必要がある場合、localStorage がより適切な選択肢です。

ブラウザー ストレージ使用時の注意事項:

• サーバー側データベースの使用に似ていますが、データの読み込みと保存は非同期です。
• プリレンダリング中はローカル ストレージを利用できません。プリレンダリング中は、要求されたページがブラウザーに存在しないためです。
• 数キロバイトのデータのストレージは、サーバー側 Blazor アプリで保持するのが妥当です。 数キロバイトを超えると、パフォーマンスに影響が出ることを考慮する必要があります。ネットワーク中でデータが読み込まれ、保存されるためです。
• ユーザーはデータを見たり、改ざんしたりするかもしれません。 ASP.NET Core のデータ保護で、このリスクを軽減できます。 たとえば、ASP.NET Core で保護されたブラウザー ストレージでは、ASP.NET Core のデータ保護が使用されます。

サードパーティ製 NuGet パッケージからは、localStorage と sessionStorage を使用するための API が与えられます。 ASP.NET Core のデータ保護を透過的に使用するパッケージを選択してみることもお勧めします。 データ保護を使用すると、保存データが暗号化され、保存データが改ざんされる潜在的リスクが減ります。 JSON でシリアル化されたデータがプレーンテキストで保存されている場合、ユーザーはブラウザー開発者ツールでデータを表示できます。また、保存データを変更できます。 些細なデータのセキュリティ保護は問題ではありません。 たとえば、UI 要素に保存されている色を読み取られたり、変更されたりしたところで、それはユーザーや組織にとって大きなセキュリティ リスクではありません。 "取り扱いに慎重を要するデータ" を見たり、改ざんしたりすることをユーザーに禁止します。

ASP.NET Core で保護されたブラウザー ストレージ

ASP.NET Core で保護されたブラウザー ストレージでは、localStorage と sessionStorage に対して ASP.NET Core のデータ保護が使用されます。

コンポーネント内でデータを保存し、読み込む

ブラウザー ストレージのデータの読み込みまたは保存が必要なすべてのコンポーネントで、@inject ディレクティブを使用して、次のいずれかのインスタンスを挿入します。

• ProtectedLocalStorage
• ProtectedSessionStorage

どれを選択するかは、使用するブラウザー ストレージの場所によって異なります。 次の例では、sessionStorage が使用されています。

@using Microsoft.AspNetCore.Components.Server.ProtectedBrowserStorage
@inject ProtectedSessionStorage ProtectedSessionStore

@using Microsoft.AspNetCore.ProtectedBrowserStorage
@inject ProtectedSessionStorage ProtectedSessionStore

@using ディレクティブは、コンポーネントの代わりに、アプリの _Imports.razor ファイルに配置できます。 _Imports.razor ファイルを使用すると、アプリの中の大きなセグメントで、あるいはアプリ全体で名前空間を利用できます。

Blazor プロジェクト テンプレートに基づいてアプリの Counter コンポーネントに currentCount の値を保持するには、ProtectedSessionStore.SetAsync を使用するように IncrementCount メソッドを変更します。

private async Task IncrementCount()
{
    currentCount++;
    await ProtectedSessionStore.SetAsync("count", currentCount);
}

もっと大規模で現実に即したアプリの場合、個々のフィールドを保管するというのはありそうにないシナリオです。 アプリでは多くの場合、状態が複雑なモデル オブジェクト全体を保存します。 ProtectedSessionStore では、複雑な状態オブジェクトを格納するため、JSON データが自動的にシリアル化および逆シリアル化されます。

前のコード例では、currentCount データは、ユーザーのブラウザーに sessionStorage['count'] として保存されます。 データはプレーンテキストに保存されず、ASP.NET Core のデータ保護を使用して保護されます。 ブラウザーの開発者コンソールで sessionStorage['count'] が評価される場合、暗号化されたデータを調べることができます。

ユーザーが後で Counter コンポーネントに戻ったときに currentCount データを回復するには (ユーザーが新しい回線にいる場合も含め)、ProtectedSessionStore.GetAsync を使用します。

protected override async Task OnInitializedAsync()
{
    var result = await ProtectedSessionStore.GetAsync<int>("count");
    currentCount = result.Success ? result.Value : 0;
}

protected override async Task OnInitializedAsync()
{
    currentCount = await ProtectedSessionStore.GetAsync<int>("count");
}

コンポーネントのパラメーターにナビゲーションの状態が含まれている場合は、ProtectedSessionStore.GetAsync を呼び出して、OnInitializedAsync ではなく、OnParametersSetAsync に null 以外の結果を割り当てます。 OnInitializedAsync は、コンポーネントが最初にインスタンス化されたときに 1 回だけ呼び出されます。 後で、その同じページにいるとき、ユーザーが別の URL に移動しても OnInitializedAsync が再び呼び出されることはありません。 詳しくは、「ASP.NET Core Razor コンポーネントのライフサイクル」をご覧ください。

読み込み状態を処理する

ブラウザー ストレージはネットワーク接続経由で非同期にアクセスされるため、データが読み込まれ、コンポーネントで利用できるようになるまでに、常に一定の時間があります。 最良の結果を得るために、読み込みが進行中には空のデータや既定のデータを表示するのではなく、メッセージをレンダリングします。

private int? currentCount;

@if (currentCount.HasValue)
{
    <p>Current count: <strong>@currentCount</strong></p>
    <button @onclick="IncrementCount">Increment</button>
}
else
{
    <p>Loading...</p>
}

プリレンダリングを処理する

プリレンダリング中:

• ユーザーのブラウザーに対話式で接続することはありません。
• ブラウザーには、JavaScript コードを実行できるページがまだありません。

localStorage または sessionStorage は、プリレンダリング中に使用できません。 コンポーネントがストレージとのやり取りを試みている場合、コンポーネントがプリレンダリングされているために JavaScript 相互運用の呼び出しを発行できないことを示すエラーが生成されます。

このエラーを解決する方法の 1 つは、プリレンダリングを無効にすることです。 これは通常、ブラウザーベースのストレージがアプリで頻繁に使用される場合、最良の選択肢となります。 プリレンダリングによってさらに複雑になり、アプリにとっては良いことがありません。アプリでは localStorage または sessionStorage が利用できなければ、役に立つコンテンツをプリレンダリングできないからです。

<Routes @rendermode="new InteractiveServerRenderMode(prerender: false)" />

<HeadOutlet @rendermode="new InteractiveServerRenderMode(prerender: false)" />

<component type="typeof(App)" render-mode="Server" />

プリレンダリングは、localStorage や sessionStorage を使用しない他のページでは役に立つかもしれません。 プリレンダリングを保持するには、ブラウザーが回線に接続されるまで読み込み操作を延期します。 次はカウンター値を格納する例です。

@using Microsoft.AspNetCore.Components.Server.ProtectedBrowserStorage
@inject ProtectedLocalStorage ProtectedLocalStore

@if (isConnected)
{
    <p>Current count: <strong>@currentCount</strong></p>
    <button @onclick="IncrementCount">Increment</button>
}
else
{
    <p>Loading...</p>
}

@code {
    private int currentCount;
    private bool isConnected;

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (firstRender)
        {
            isConnected = true;
            await LoadStateAsync();
            StateHasChanged();
        }
    }

    private async Task LoadStateAsync()
    {
        var result = await ProtectedLocalStore.GetAsync<int>("count");
        currentCount = result.Success ? result.Value : 0;
    }

    private async Task IncrementCount()
    {
        currentCount++;
        await ProtectedLocalStore.SetAsync("count", currentCount);
    }
}

@using Microsoft.AspNetCore.ProtectedBrowserStorage
@inject ProtectedLocalStorage ProtectedLocalStore

@if (isConnected)
{
    <p>Current count: <strong>@currentCount</strong></p>
    <button @onclick="IncrementCount">Increment</button>
}
else
{
    <p>Loading...</p>
}

@code {
    private int currentCount = 0;
    private bool isConnected = false;

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (firstRender)
        {
            isConnected = true;
            await LoadStateAsync();
            StateHasChanged();
        }
    }

    private async Task LoadStateAsync()
    {
        currentCount = await ProtectedLocalStore.GetAsync<int>("count");
    }

    private async Task IncrementCount()
    {
        currentCount++;
        await ProtectedLocalStore.SetAsync("count", currentCount);
    }
}

状態保存を取り出し、共通の場所に入れる

さまざまなコンポーネントがブラウザーベースのストレージに依存している場合、状態プロバイダー コードを何回も実装すると、コードが重複します。 コードの重複を回避する選択肢の 1 つは、状態プロバイダー ロジックをカプセル化する "状態プロバイダーの親コンポーネント" を作成することです。 状態保存メカニズムに関係なく、子コンポーネントは永続保存データとやりとりできます。

CounterStateProvider コンポーネントの次の例では、カウンター データは sessionStorage に保持されます。

@using Microsoft.AspNetCore.Components.Server.ProtectedBrowserStorage
@inject ProtectedSessionStorage ProtectedSessionStore

@if (isLoaded)
{
    <CascadingValue Value="this">
        @ChildContent
    </CascadingValue>
}
else
{
    <p>Loading...</p>
}

@code {
    private bool isLoaded;

    [Parameter]
    public RenderFragment? ChildContent { get; set; }

    public int CurrentCount { get; set; }

    protected override async Task OnInitializedAsync()
    {
        var result = await ProtectedSessionStore.GetAsync<int>("count");
        CurrentCount = result.Success ? result.Value : 0;
        isLoaded = true;
    }

    public async Task SaveChangesAsync()
    {
        await ProtectedSessionStore.SetAsync("count", CurrentCount);
    }
}

@using Microsoft.AspNetCore.ProtectedBrowserStorage
@inject ProtectedSessionStorage ProtectedSessionStore

@if (isLoaded)
{
    <CascadingValue Value="this">
        @ChildContent
    </CascadingValue>
}
else
{
    <p>Loading...</p>
}

@code {
    private bool isLoaded;

    [Parameter]
    public RenderFragment ChildContent { get; set; }

    public int CurrentCount { get; set; }

    protected override async Task OnInitializedAsync()
    {
        CurrentCount = await ProtectedSessionStore.GetAsync<int>("count");
        isLoaded = true;
    }

    public async Task SaveChangesAsync()
    {
        await ProtectedSessionStore.SetAsync("count", CurrentCount);
    }
}

CounterStateProvider コンポーネントによって読み込み段階が処理されます。状態の読み込みが完了するまで、その子コンテンツがレンダリングされることはありません。

<Routes @rendermode="InteractiveServer" />

<CounterStateProvider>
    <Router ...>
        ...
    </Router>
</CounterStateProvider>

ラップされたコンポーネントの元に永続化されたカウンター状態が届くので、それを変更できます。 次の Counter コンポーネントはパターンが実装されています。

@page "/counter"

<p>Current count: <strong>@CounterStateProvider?.CurrentCount</strong></p>
<button @onclick="IncrementCount">Increment</button>

@code {
    [CascadingParameter]
    private CounterStateProvider? CounterStateProvider { get; set; }

    private async Task IncrementCount()
    {
        if (CounterStateProvider is not null)
        {
            CounterStateProvider.CurrentCount++;
            await CounterStateProvider.SaveChangesAsync();
        }
    }
}

このコンポーネントは ProtectedBrowserStorage とやりとりするために必要ありませんし、"読み込み" 段階にも関係ありません。

前に説明したようにプリレンダリングを扱うには、カウンター データを利用するすべてのコンポーネントが自動的にプリレンダリングを使用するよう、CounterStateProvider を変更できます。 詳細については、「プリレンダリングを処理する」セクションを参照してください。

一般に、次の場合、"状態プロバイダーの親コンポーネント" パターンが推奨されます。

• 多くのコンポーネントで状態を使用する。
• 最上位の状態オブジェクトを 1 つだけ保持する場合。

さまざまな状態オブジェクトを保持し、さまざまな場所でさまざまなオブジェクト サブセットを使用するには、状態をグローバルに保持しないことをお勧めします。

Blazor WebAssembly アプリで作成されたユーザー状態は、ブラウザーのメモリに保持されます。

ブラウザーのメモリに保持されるユーザー状態の例としては、次のようなものがあります。

• レンダリングされた UI での、コンポーネント インスタンスの階層と最新のレンダリング出力。
• コンポーネント インスタンスに含まれるフィールドとプロパティの値。
• 依存関係の挿入 (DI) サービス インスタンスに保持されているデータ。
• JavaScript 相互運用の呼び出しによって設定された値。

ユーザーがブラウザーを閉じてから再度開いたり、ページを再度読み込んだりすると、ブラウザーのメモリに保持されているユーザー状態は失われます。

ブラウザー セッション間で状態を保持する

一般に、ユーザーが既存データを単に読み取るのではなく、活発にデータを作成している場合は、ブラウザー セッション間で状態を保持します。

ブラウザー セッション間で状態を維持するには、アプリで、ブラウザーのメモリとは異なる他の保存場所に、データを保持する必要があります。 状態は自動的に保存されません。 ステートフルなデータ保存を実装するアプリを開発するとき、措置を講じる必要があります。

データの保持は、通常、作成するためにユーザーが大きな労力を費やした、価値の高い状態の場合にのみ必要です。 次の例では、状態を維持することで、時間が節約され、商業活動の支援になります。

• 複数ステップの Web フォーム: 複数ステップの Web フォームのいくつかのステップを完了した後で、状態が失われた場合、ユーザーがデータを再入力するのでは時間がかかります。 このシナリオでは、フォームからユーザーが離れて後で戻ってきた場合、状態が失われます。
• ショッピング カート: 収益につながる可能性がある、アプリの中のビジネス上重要なコンポーネントを維持できます。 ユーザーが自分の状態を失い、そのため、自分のショッピング カートが消えると、後でサイトに戻ってきたとき、製品やサービスの購入数が減ることがあります。

アプリでは、"アプリの状態" のみが維持されます。 コンポーネント インスタンスやそのレンダー ツリーなど、UI は維持されません。 コンポーネントとレンダー ツリーは一般的にシリアル化されません。 アプリで、ツリー ビュー コントロールの展開されたノードなど、UI の状態を維持するには、カスタム コードを使用して、UI 状態の動作をシリアル化できるアプリ状態としてモデル化する必要があります。

状態を維持する場所

一般に、状態を維持するために、次のような場所があります。

• サーバー側ストレージ
• URL
• ブラウザー ストレージ
• メモリ内状態コンテナー サービス

サーバー側ストレージ

複数のユーザーとデバイスにまたがって永続的にデータを保持する場合は、Web API を使用してアクセスされる独立したサーバー側ストレージをアプリで使用できます。 次のオプションがあります。

• BLOB ストレージ
• キーと値のストレージ
• リレーショナル データベース
• テーブル ストレージ

データが保存された後は、ユーザーの状態は保持されていて、新しいブラウザー セッションで使用できます。

Blazor WebAssembly アプリはユーザーのブラウザー内で完全に実行されるため、ストレージ サービスやデータベースなど、セキュリティで保護された外部システムにアクセスするには、追加の手段が必要です。 Blazor WebAssembly アプリは、シングル ページ アプリケーション (SPA) と同じ方法でセキュリティ保護されます。 通常、アプリでは、OAuth や OpenID Connect (OIDC) を使用してユーザーの認証を行った後、サーバー側アプリへの Web API 呼び出しを使用して、ストレージ サービスやデータベースとやり取りします。 Blazor WebAssembly アプリとストレージ サービスまたはデータベースの間のデータ転送は、サーバー側アプリによって仲介されます。 Blazor WebAssembly アプリではサーバー側アプリへの一時的な接続を維持し、サーバー側アプリではストレージへの永続的な接続が保持されます。

詳細については、次のリソースを参照してください。

• ASP.NET Core Blazor アプリから Web API を呼び出す
• ASP.NET Core をセキュリティで保護するBlazor WebAssembly
• Blazor の "セキュリティと Identity" に関する記事

Azure のデータ ストレージ オプションの詳細については、以下を参照してください。

• Azure のデータベース
• Azure Storage のドキュメント

URL

ナビゲーションの状態を表わす一時的なデータについては、URL の一部としてデータをモデル化します。 たとえば、次のようなユーザー状態が URL でモデル化されます。

• 表示されるエンティティの ID。
• ページ付きグリッドでの現在のページ番号。

ユーザーが手動でページを再度読み込むと、ブラウザーのアドレス バーの内容が保持されます。

@page ディレクティブで URL パターンを定義する方法については、「ASP.NET Core の Blazor ルーティングとナビゲーション」をご覧ください。

ブラウザー ストレージ

ユーザーが頻繁に作成する一時的なデータの場合、一般的に使用されるストレージの場所は、ブラウザーの localStorage コレクションと sessionStorage コレクションです。

• localStorage の対象範囲はブラウザーのウィンドウです。 ユーザーがページを再読み込みするか、ブラウザーを閉じてから再度開いた場合、状態は保持されます。 ユーザーが複数のブラウザー タブを開くと、状態はすべてのタブで同じになります。 データは直接消去されるまで localStorage に残ります。
• sessionStorage の対象範囲はブラウザーのタブです。ユーザーがタブを再読み込みすると、状態は維持されます。 ユーザーがタブかブラウザーを閉じると、状態は失われます。 ユーザーが複数のブラウザー タブを開くと、それぞれのタブには、他に依存しないそのタブだけのバージョンのデータが保持されます。

一般に、sessionStorage を使用しておけば安全です。 sessionStorage の場合、ユーザーが複数のタブを開き、以下に遭遇するリスクが回避されます。

• タブ間の状態保存に含まれるバグ。
• タブで他のタブの状態が上書きされるときの紛らわしい動作。

ブラウザーを閉じてから再度開いてもアプリで状態が保持される必要がある場合、localStorage がより適切な選択肢です。