Gestion de l’état d’ASP.NET Core Blazor

Blazor côté serveur est un framework d’application avec état. La plupart du temps, l’application maintient une connexion au serveur. L’état de l’utilisateur est conservé dans la mémoire du serveur dans un circuit.

Voici quelques exemples d’état utilisateur conservé dans un circuit :

• Hiérarchie des instances de composant et leur sortie de rendu la plus récente dans l’interface utilisateur rendue.
• Valeurs des champs et des propriétés dans les instances de composant.
• Données conservées dans des instances de service d’injection de dépendances (DI) qui sont limitées au circuit.

L’état utilisateur peut également se trouver dans des variables JavaScript dans le jeu de mémoire du navigateur via des appels d’interopérabilité JavaScript.

Si un utilisateur subit une perte temporaire de connexion réseau, Blazor tente de reconnecter l’utilisateur à son circuit d’origine avec son état d’origine. Toutefois, il n’est pas toujours possible de reconnecter un utilisateur à son circuit d’origine dans la mémoire du serveur :

• Le serveur ne peut pas conserver un circuit déconnecté indéfiniment. Le serveur doit libérer un circuit déconnecté après un délai d’expiration ou lorsque le serveur a besoin de mémoire.
• Dans les environnements de déploiement multiserveurs et à charge équilibrée, des serveurs individuels peuvent échouer ou être automatiquement supprimés lorsqu’ils ne sont plus nécessaires pour gérer le volume global de requêtes. Le serveur d’origine qui traite les requêtes d’un utilisateur peut devenir indisponible lorsque l’utilisateur tente de se reconnecter.
• L’utilisateur peut fermer et rouvrir son navigateur ou recharger la page, ce qui supprime tout état conservé dans la mémoire du navigateur. Par exemple, les valeurs des variables JavaScript définies par le biais d’appels d’interopérabilité JavaScript sont perdues.

Lorsqu’un utilisateur ne peut pas être reconnecté à son circuit d’origine, il reçoit un nouveau circuit avec un état vide. Cela revient à fermer et à rouvrir une application de bureau.

Conserver l’état sur les circuits

En règle générale, conservez l’état sur les circuits où les utilisateurs créent activement des données, et pas simplement en lisant des données qui existent déjà.

Pour conserver l’état sur les circuits, l’application doit conserver les données dans un autre emplacement de stockage que la mémoire du serveur. La persistance d’état n’est pas automatique. Vous devez prendre des mesures lors du développement de l’application pour implémenter la persistance des données avec état.

La persistance des données n’est généralement requise que pour l’état à valeur élevée que les utilisateurs ont consacré des efforts à créer. Dans les exemples suivants, l’état persistant fait gagner du temps ou facilite les activités commerciales :

• Formulaires web à plusieurs étapes : il est fastidieux pour un utilisateur de saisir à nouveau des données pour plusieurs étapes terminées d’un formulaire web à plusieurs étapes si leur état est perdu. Un utilisateur perd l’état dans ce scénario s’il quitte le formulaire et revient ultérieurement.
• Paniers d’achat : tout composant important sur le plan commercial d’une application qui représente le chiffre d’affaires potentiel peut être conservé. Un utilisateur qui perd son état, et donc son panier d’achat, est susceptible d’acheter moins de produits ou de services lorsqu’il revient sur le site plus tard.

Une application peut uniquement conserver l’état de l’application. Les interfaces utilisateur ne peuvent pas être conservées, comme les instances de composant et leurs arborescences de rendu. Les composants et les arborescences de rendu ne sont généralement pas sérialisables. Pour conserver l’état de l’interface utilisateur, comme les nœuds développés d’un contrôle d’arborescence, l’application doit utiliser du code personnalisé pour modéliser le comportement de l’état de l’interface utilisateur comme état de l’application sérialisable.

Où conserver l’état

Il existe des emplacements courants pour conserver l’état :

• Stockage côté serveur
• URL
• Stockage du navigateur
• Service de conteneur d’état en mémoire

Stockage côté serveur

Pour une persistance permanente des données qui s’étend sur plusieurs utilisateurs et appareils, l’application peut utiliser le stockage côté serveur. Voici les options :

• Stockage Blob
• Stockage de clé-valeur
• Base de données relationnelle
• Stockage de tables

Une fois les données enregistrées, l’état de l’utilisateur est conservé et disponible dans tout nouveau circuit.

Pour plus d’informations sur les options de stockage de données Azure, consultez les rubriques suivantes :

• Bases de données Azure
• Documentation d’Azure Storage

URL

Pour les données temporaires représentant l’état de navigation, modélisez les données dans le cadre de l’URL. Voici quelques exemples d’état utilisateur modélisé dans l’URL :

• ID d’une entité consultée.
• Numéro de page actuel dans une grille paginée.

Le contenu de la barre d’adresse du navigateur est conservé :

• Si l’utilisateur recharge manuellement la page.
• Si le serveur web devient indisponible et que l’utilisateur est obligé de recharger la page pour se connecter à un autre serveur.

Pour plus d’informations sur la définition de modèles d’URL avec la directive @page, consultez Routage et navigation avec ASP.NET Core Blazor.

Stockage du navigateur

Pour les données temporaires que l’utilisateur crée activement, les collections localStorage et sessionStorage sont un emplacement de stockage couramment utilisé :

• localStorage est limité à la fenêtre du navigateur. Si l’utilisateur recharge la page ou ferme et rouvre le navigateur, l’état persiste. Si l’utilisateur ouvre plusieurs onglets de navigateur, l’état est partagé entre les onglets. Les données sont conservées dans localStorage jusqu’à leur effacement explicite.
• sessionStorage est limité à l’onglet du navigateur. Si l’utilisateur recharge l’onglet, l’état persiste. Si l’utilisateur ferme l’onglet ou le navigateur, l’état est perdu. Si l’utilisateur ouvre plusieurs onglets de navigateur, chaque onglet a sa propre version indépendante des données.

En général, sessionStorage est plus sûr à utiliser. sessionStorage évite le risque qu’un utilisateur ouvre plusieurs onglets et rencontre les problèmes suivants :

• Bogues dans le stockage d’état entre les onglets.
• Comportement confus lorsqu’un onglet remplace l’état d’autres onglets.

localStorage est le meilleur choix si l’application doit conserver l’état pendant la fermeture et la réouverture du navigateur.

Mises en garde pour l’utilisation du stockage du navigateur :

• À l’instar de l’utilisation d’une base de données côté serveur, le chargement et l’enregistrement des données sont asynchrones.
• Le stockage local n’est pas disponible pendant le prérendu, car la page demandée n’existe pas dans le navigateur pendant le prérendu.
• Il est raisonnable de stocker quelques kilo-octets de données pour les applications Blazor côté serveur. Au-delà de quelques kilo-octets, vous devez prendre en compte les implications en matière de performances, car les données sont chargées et enregistrées sur le réseau.
• Les utilisateurs pourraient afficher ou falsifier les données. La protection des données ASP.NET Core peut atténuer le risque. Par exemple, le stockage du navigateur protégé ASP.NET Core utilise la protection des données ASP.NET Core.

Les packages NuGet tiers fournissent des API permettant d’utiliser localStorage et sessionStorage. Il est utile de choisir un package qui utilise de manière transparente la protection des données ASP.NET Core. La protection des données chiffre les données stockées et réduit le risque potentiel de falsification des données stockées. Si les données sérialisées en JSON sont stockées en texte brut, les utilisateurs peuvent voir les données à l’aide des outils de développement du navigateur et modifier les données stockées. La sécurisation des données triviales n’est pas un problème. Par exemple, la lecture ou la modification de la couleur stockée d’un élément d’interface utilisateur n’est pas un risque de sécurité significatif pour l’utilisateur ou l’organisation. Évitez d’autoriser les utilisateurs à inspecter ou à falsifier les données sensibles.

Stockage du navigateur protégé ASP.NET Core

Le stockage par navigateur protégé ASP.NET Core tire parti de la protection des données ASP.NET Core pour localStorage et sessionStorage.

Enregistrer et charger des données dans un composant

Dans tout composant nécessitant le chargement ou l’enregistrement de données dans le stockage du navigateur, utilisez la directive @inject pour injecter une des instances suivantes :

• ProtectedLocalStorage
• ProtectedSessionStorage

Le choix dépend de l’emplacement de stockage du navigateur que vous souhaitez utiliser. sessionStorage est utilisé dans l’exemple suivant :

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

@using Microsoft.AspNetCore.ProtectedBrowserStorage
@inject ProtectedSessionStorage ProtectedSessionStore

La directive @using peut être placée dans le fichier _Imports.razor de l’application au lieu du composant. L’utilisation du fichier _Imports.razor rend l’espace de noms disponible pour les segments plus volumineux de l’application ou l’ensemble de l’application.

Pour conserver la valeur currentCount dans le composant Counter d’une application en fonction du modèle de projet Blazor, modifiez la méthode IncrementCount pour utiliser ProtectedSessionStore.SetAsync :

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

Dans les applications plus grandes et plus réalistes, le stockage de champs individuels est un scénario peu probable. Les applications sont plus susceptibles de stocker des objets de modèle entiers qui incluent un état complexe. ProtectedSessionStore sérialise et désérialise automatiquement les données JSON pour stocker des objets d’état complexes.

Dans l’exemple de code précédent, les données currentCount sont stockées en tant que sessionStorage['count'] dans le navigateur de l’utilisateur. Les données ne sont pas stockées en texte brut, mais sont plutôt protégées à l’aide de la protection des données ASP.NET Core. Les données chiffrées peuvent être inspectées si sessionStorage['count'] est évalué dans la console du développeur du navigateur.

Pour récupérer les données currentCount si l’utilisateur revient au composant Counter ultérieurement, notamment si l’utilisateur se trouve sur un nouveau circuit, utilisez 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");
}

Si les paramètres du composant incluent l’état de navigation, appelez ProtectedSessionStore.GetAsync et affectez un résultat non null dans OnParametersSetAsync, et non OnInitializedAsync. OnInitializedAsync n’est appelé qu’une seule fois lorsque le composant est instancié pour la première fois. OnInitializedAsync n’est pas appelé ultérieurement si l’utilisateur accède à une autre URL tout en restant sur la même page. Pour plus d’informations, consultez le cycle de vie des composants Razor ASP.NET Core.

Gérer l’état de chargement

Étant donné que le stockage du navigateur est accessible de manière asynchrone via une connexion réseau, il existe toujours un délai avant que les données soient chargées et disponibles pour un composant. Pour obtenir de meilleurs résultats, affichez un message pendant le chargement en cours au lieu d’afficher des données vides ou par défaut.

private int? currentCount;

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

Gérer le prérendu

Pendant le prérendu :

• Il n’existe pas de connexion interactive au navigateur de l’utilisateur.
• Le navigateur n’a pas encore de page dans laquelle il peut exécuter du code JavaScript.

localStorage ou sessionStorage ne sont pas disponibles lors du prérendu. Si le composant tente d’interagir avec le stockage, une erreur est générée expliquant que les appels d’interopérabilité JavaScript ne peuvent pas être émis, car le composant est en cours de prérendu.

L’un des moyens de résoudre l’erreur consiste à désactiver le prérendu. Il s’agit généralement du meilleur choix si l’application utilise intensivement le stockage basé sur un navigateur. Le prérendu ajoute de la complexité et n’est pas bénéfique pour l’application, car l’application ne peut pas prérendre du contenu utile tant que localStorage ou sessionStorage n’est pas disponible.

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

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

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

Le prérendu peut être utile pour d’autres pages qui n’utilisent pas localStorage ou sessionStorage. Pour conserver le prérendu, reportez l’opération de chargement jusqu’à ce que le navigateur soit connecté au circuit. Voici un exemple de stockage d’une valeur de compteur :

@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);
    }
}

Factoriser la conservation de l’état à un emplacement commun

Si de nombreux composants s’appuient sur un stockage basé sur le navigateur, l’implémentation du code du fournisseur d’état crée souvent une duplication de code. L’une des options permettant d’éviter la duplication du code consiste à créer un composant parent du fournisseur d’état qui encapsule la logique du fournisseur d’état. Les composants enfants peuvent fonctionner avec des données persistantes sans tenir compte du mécanisme de persistance d’état.

Dans l’exemple suivant d’un composant CounterStateProvider, les données de compteur sont conservées dans 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);
    }
}

Le composant CounterStateProvider gère la phase de chargement en ne rendant pas son contenu enfant tant que le chargement de l’état n’est pas terminé.

<Routes @rendermode="InteractiveServer" />

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

Les composants encapsulés reçoivent et peuvent modifier l’état persistant du compteur. Le composant Counter suivant implémente le modèle :

@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();
        }
    }
}

Le composant précédent n’est pas obligatoire pour interagir avec ProtectedBrowserStorage, et il ne traite pas non plus de phase de « chargement ».

Pour traiter le prérendu comme décrit précédemment, CounterStateProvider peut être modifié de sorte que tous les composants qui consomment les données du compteur fonctionnent automatiquement avec le prérendu. Pour plus d’informations, consultez la section Gérer le prérendu.

En règle générale, le modèle composant parent du fournisseur d’état est recommandé :

• Pour consommer l’état sur de nombreux composants.
• S’il n’y a qu’un seul objet d’état de niveau supérieur à conserver.

Pour conserver de nombreux objets d’état différents et consommer différents sous-ensembles d’objets à différents emplacements, il est préférable d’éviter la persistance de l’état à l’échelle globale.

L’état utilisateur créé dans une application Blazor WebAssembly est conservé dans la mémoire du navigateur.

Voici des exemples d’état utilisateur conservé dans la mémoire du navigateur :

• Hiérarchie des instances de composant et leur sortie de rendu la plus récente dans l’interface utilisateur rendue.
• Valeurs des champs et des propriétés dans les instances de composant.
• Données conservées dans des instances de service d’injection de dépendances (DI).
• Valeurs définies via des appels d’interopérabilité JavaScript.

Lorsqu’un utilisateur ferme et rouvre son navigateur ou recharge la page, l’état utilisateur conservé dans la mémoire du navigateur est perdu.

Conserver l’état entre sessions de navigateur

En règle générale, conservez l’état sur les sessions de navigateur où les utilisateurs créent activement des données, et pas simplement en lisant des données qui existent déjà.

Pour conserver l’état entre sessions de navigateur, l’application doit conserver les données dans un autre emplacement de stockage que la mémoire du navigateur. La persistance d’état n’est pas automatique. Vous devez prendre des mesures lors du développement de l’application pour implémenter la persistance des données avec état.

La persistance des données n’est généralement requise que pour l’état à valeur élevée que les utilisateurs ont consacré des efforts à créer. Dans les exemples suivants, l’état persistant fait gagner du temps ou facilite les activités commerciales :

• Formulaires web à plusieurs étapes : il est fastidieux pour un utilisateur de saisir à nouveau des données pour plusieurs étapes terminées d’un formulaire web à plusieurs étapes si leur état est perdu. Un utilisateur perd l’état dans ce scénario s’il quitte le formulaire et revient ultérieurement.
• Paniers d’achat : tout composant important sur le plan commercial d’une application qui représente le chiffre d’affaires potentiel peut être conservé. Un utilisateur qui perd son état, et donc son panier d’achat, est susceptible d’acheter moins de produits ou de services lorsqu’il revient sur le site plus tard.

Une application peut uniquement conserver l’état de l’application. Les interfaces utilisateur ne peuvent pas être conservées, comme les instances de composant et leurs arborescences de rendu. Les composants et les arborescences de rendu ne sont généralement pas sérialisables. Pour conserver l’état de l’interface utilisateur, comme les nœuds développés d’un contrôle d’arborescence, l’application doit utiliser du code personnalisé pour modéliser le comportement de l’état de l’interface utilisateur comme état de l’application sérialisable.

Où conserver l’état

Il existe des emplacements courants pour conserver l’état :

• Stockage côté serveur
• URL
• Stockage du navigateur
• Service de conteneur d’état en mémoire

Stockage côté serveur

Pour une persistance permanente des données qui s’étend sur plusieurs utilisateurs et appareils, l’application peut utiliser un stockage indépendant côté serveur accessible via une API web. Voici les options :

• Stockage Blob
• Stockage de clé-valeur
• Base de données relationnelle
• Stockage de tables

Une fois les données enregistrées, l’état de l’utilisateur est conservé et disponible dans toute nouvelle session de navigateur.

Étant donné que les applications Blazor WebAssembly s’exécutent entièrement dans le navigateur de l’utilisateur, elles nécessitent des mesures supplémentaires pour accéder à des systèmes externes sécurisés, comme les services de stockage et les bases de données. Les applications Blazor WebAssembly sont sécurisées de la même manière que les applications monopages (SPA). En règle générale, une application authentifie un utilisateur via OAuth/OpenID Connect (OIDC), puis interagit avec les services de stockage et les bases de données par le biais d’appels d’API web à une application côté serveur. L’application côté serveur gère le transfert de données entre l’application Blazor WebAssembly et le service de stockage ou la base de données. L’application Blazor WebAssembly maintient une connexion éphémère à l’application côté serveur, tandis que l’application côté serveur dispose d’une connexion permanente au stockage.

Pour en savoir plus, consultez les ressources suivantes :

• Appeler une API web à partir d’une application ASP.NET Core Blazor
• Sécuriser ASP.NET Core Blazor WebAssembly
• BlazorArticles Sécurité et Identity

Pour plus d’informations sur les options de stockage de données Azure, consultez les rubriques suivantes :

• Bases de données Azure
• Documentation d’Azure Storage

URL

Pour les données temporaires représentant l’état de navigation, modélisez les données dans le cadre de l’URL. Voici quelques exemples d’état utilisateur modélisé dans l’URL :

• ID d’une entité consultée.
• Numéro de page actuel dans une grille paginée.

Le contenu de la barre d’adresse du navigateur est conservé si l’utilisateur recharge manuellement la page.

Pour plus d’informations sur la définition de modèles d’URL avec la directive @page, consultez Routage et navigation avec ASP.NET Core Blazor.

Stockage du navigateur

Pour les données temporaires que l’utilisateur crée activement, les collections localStorage et sessionStorage sont un emplacement de stockage couramment utilisé :

• localStorage est limité à la fenêtre du navigateur. Si l’utilisateur recharge la page ou ferme et rouvre le navigateur, l’état persiste. Si l’utilisateur ouvre plusieurs onglets de navigateur, l’état est partagé entre les onglets. Les données sont conservées dans localStorage jusqu’à leur effacement explicite.
• sessionStorage est limité à l’onglet du navigateur. Si l’utilisateur recharge l’onglet, l’état persiste. Si l’utilisateur ferme l’onglet ou le navigateur, l’état est perdu. Si l’utilisateur ouvre plusieurs onglets de navigateur, chaque onglet a sa propre version indépendante des données.

En général, sessionStorage est plus sûr à utiliser. sessionStorage évite le risque qu’un utilisateur ouvre plusieurs onglets et rencontre les problèmes suivants :

• Bogues dans le stockage d’état entre les onglets.
• Comportement confus lorsqu’un onglet remplace l’état d’autres onglets.

localStorage est le meilleur choix si l’application doit conserver l’état pendant la fermeture et la réouverture du navigateur.