Stockage local pour enregistrer et restaurer l’entrée du formulaire

Nous apprendrons à tirer parti de l’API de stockage locale pour stocker l’état d’application temporaire dans Blazor WebAssembly.

Dans les applications Web, nous devons jouer dans les règles et limites que les navigateurs Web fournissent à nos applications.

Par exemple, contrairement aux applications de bureau, où nous avons un contrôle complet sur l’état de notre application, les utilisateurs d’applications Web peuvent revenir en arrière ou même fermer l’onglet actif ou le navigateur entier à tout moment. Cette circonstance oblige les développeurs Web à consacrer plus d’efforts à gérer l’état d’application.

Dans cet article, nous apprendrons à utiliser le stockage local dans Blazor WebAssembly pour enregistrer et restaurer l’entrée du formulaire dans les applications Web basées sur les données.

Le concept

Au lieu de perdre tout l’état d’application lorsque l’utilisateur actualise la page, nous voulons enregistrer les valeurs qu’ils ont entrées dans les champs de formulaire à l’aide de stockage local, une API du navigateur Web standard. Nous utiliserons un formulaire de contact simple, mais ce concept peut être étendu et utilisé pour gérer l’état d’application complexe, tels que les workflows complets.

Chaque fois qu’un utilisateur quitte un champ, nous voulons stocker la valeur dans le stockage local. Avec cette stratégie, nous pouvons par la suite recharger les données du stockage local lorsque l’utilisateur revient après une rupture (non) prévue de travailler dans l’application.

Prime: Au lieu de restaurer avec force l’état d’application, nous pouvons aller plus loin et laisser l’utilisateur choisir de réinstaller l’état précédent, de commencer à zéro avec le flux de travail ou de remplir les champs de formulaire. Cependant, cela dépasse le cadre de cet exemple.

Je mettrai en évidence les parties les plus critiques du code de cet article, mais je laisse de côté les morceaux pour éviter trop de faire gonfler l’article. Tu peux accéder au code utilisé dans cet exemple sur github.

Tout d’abord, créons un Contact Composant de page contenant un formulaire avec des champs typiques pour un tel scénario.

Nous avons des champs de nom, e-mail, sujet, messages et un Send Message bouton.

Le code de modèle dans le Contact.razor Le composant de page ressemble à ceci:

@page "https://www.telerik.com/contact"
@using System.ComponentModel.DataAnnotations
<PageTitle>Contact</PageTitle>
<h1>Contact</h1>

<EditForm Model="@Model" OnValidSubmit="@HandleValidSubmit" FormName="Contact">
    <DataAnnotationsValidator />
    <ValidationSummary />

    <InputText id="name"
		Value="@Model.Name"
        ValueChanged="@(async value => await OnFieldChanged(nameof(Model.Name), value))"
        ValueExpression="@(() => Model.Name)" />
    <InputText id="email" type="email" class="form-control" 
        Value="@Model.Email"
        ValueChanged="@(async value => await OnFieldChanged(nameof(Model.Email), value))"
        ValueExpression="@(() => Model.Email)" />
    <InputText id="subject" class="form-control" 
        Value="@Model.Subject"
        ValueChanged="@(async value => await OnFieldChanged(nameof(Model.Subject), value))"
        ValueExpression="@(() => Model.Subject)" />
	<InputTextArea id="message" class="form-control" Rows="5" 
        Value="@Model.Message"
        ValueChanged="@(async value => await OnFieldChanged(nameof(Model.Message), value))"
        ValueExpression="@(() => Model.Message)" />

    <button type="submit">Send Message</button>
</EditForm>

@if (isSubmitted)
{
    <div>
        Thank you! Your message has been sent.
    </div>
}

Encore une fois, j’ai raccourci l’exemple de code indiqué ici et supprimé le style CSS, principalement des classes bootstrap, pour la rendre plus expressive et concise.

Indice: Nous utilisons le EditForm Composant, qui est utile pour la gestion des formulaires. Voir le Validation avancée du formulaire de blazor Article pour plus de détails sur la façon dont le EditForm Composant fonctionne.

Nous utilisons le DataAnnotationsValidator et ValidationSummary composants à l’intérieur du EditForm composant et le InputText et InputTextArea Composants pour rendre les champs d’entrée.

La différence la plus notable entre une forme régulière et cet exemple est que nous n’utilisons pas le @bind-Value directif. Au lieu de cela, nous lions le Value, ValueChanged et ValueExpression propriétés individuellement.

Il nous donne plus de contrôle sur le comportement, en particulier l’exécution du code lorsque la valeur change. Dans cet exemple, nous appelons un OnFieldChanged Méthode et fournissez le nom du champ et sa valeur.

Enfin, nous avons une section de rendu conditionnel montrant un message de remerciement lorsque le formulaire a été soumis.

Regardons maintenant la section Code du composant.

@code {
	private ContactModel Model = new ContactModel();
	private bool isSubmitted = false;
	
	private void HandleValidSubmit()
	{
		isSubmitted = true;
	}
	
	public class ContactModel
	{
		[Required(ErrorMessage = "Name is required.")]
		public string Name { get; set; } = string.Empty;

		[Required(ErrorMessage = "Email is required.")]
		[EmailAddress(ErrorMessage = "Invalid email address.")]
		public string Email { get; set; } = string.Empty;

		[Required(ErrorMessage = "Subject is required.")]
		public string Subject { get; set; } = string.Empty;

		[Required(ErrorMessage = "Message is required.")]
		[StringLength(1000, ErrorMessage = "Message is too long.")]
		public string Message { get; set; } = string.Empty;
	}
}

Ici, nous avons le Model propriété que nous faisons référence dans le code de modèle, qui contient le Name, Email, Subject et Message champs. Nous utilisons des annotations de données pour implémenter les règles de validation de base.

Le HandleValidSubmit La méthode stocke généralement les données de la base de données ou appelle un service distant. Dans cet exemple isolé, nous avons défini le isSubmitted champ vers vrai.

Ce changement de propriété déclenchera un rerender et montrera le Merci Message à l’écran après qu’un utilisateur appuye sur le Send Message bouton.

Stockage de l’entrée de l’utilisateur dans le stockage local

Maintenant que nous avons le formulaire prêt, nous voulons ajouter les fonctionnalités pour stocker l’entrée utilisateur dans le stockage local.

Tout d’abord, nous ajoutons une utilisation au System.Text.Json espace de noms et injecter une instance du IJSRuntime objet.

@using System.Text.Json
@inject IJSRuntime JS

Ensuite, nous ajoutons un champ statique contenant une clé pour identifier les informations stockées dans le stockage local:

private const string StorageKey = "ContactForm";

Nous devons utiliser l’interopérabilité JavaScript pour accéder aux API du navigateur natif de Blazor.

Indice: Si vous n’avez jamais utilisé l’interopérabilité JavaScript dans Blazor auparavant, vous voudrez peut-être apprendre les fondamentaux dans le Blazor JavaScript Interop – Appelant JavaScript de .net article.

Ensuite, nous implémentons un StoreItem et un LoadItem Méthode, qui accède au stockage local et à stocker ou à charger des données.

public ValueTask StoreItem(string key, object data)
{
    return JS.InvokeVoidAsync("localStorage.setItem", new object[]
    {
        key,
        JsonSerializer.Serialize(data)
    });
}

Dans le StoreItem Méthode, nous avons deux paramètres. Le premier paramètre accepte une clé et le second est un objet .NET.

Dans l’implémentation, nous utilisons l’objet injecté de type IJSRuntime et son InvokeVoidAsync Méthode pour appeler le localStorage.setItem Fonction dans JavaScript. Nous fournissons la clé et une version sérialisée de l’objet de données transmis à la méthode au setItem fonction.

public async Task<T?> LoadItem<T>(string key)
{
    var data = await JS.InvokeAsync<string>("localStorage.getItem", key);
    if (!string.IsNullOrEmpty(data))
    {
        return JsonSerializer.Deserialize<T>(data);
    }

    return default;
}

Le LoadItem La méthode est générique et accepte la clé comme son paramètre de méthode unique. Nous utilisons JavaScript Interop pour appeler le localStorage.getItem fonction et fournissez la clé. Nous renvoyons ensuite l’objet désérialisé ou null.

Avec ces méthodes disponibles, nous pouvons enfin implémenter le OnFieldChanged Méthode référencée dans le ValueChanged Événements des champs d’entrée de formulaire.

private async Task OnFieldChanged(string fieldName, object? newValue)
{
    if (fieldName == nameof(Model.Name))
    {
        Model.Name = newValue?.ToString() ?? string.Empty;
    }   
    if (fieldName == nameof(Model.Email))
    {
        Model.Email = newValue?.ToString() ?? string.Empty;
    }
    if (fieldName == nameof(Model.Subject))
    {
        Model.Subject = newValue?.ToString() ?? string.Empty;
    }
    if (fieldName == nameof(Model.Message))
    {
        Model.Message = newValue?.ToString() ?? string.Empty;
    }

    await StoreItem(StorageKey, Model);
}

Ici, nous pouvons implémenter une logique personnalisée en fonction du champ OnFieldChanged Méthode déclenchée. Dans cet exemple, je reste simple et j’attribue la nouvelle valeur à la propriété sur la Model Objet pour chaque champ de saisie.

Indépendamment de ce que le champ a changé, nous appelons le StoreItem Méthode à la fin de la mise en œuvre de la méthode pour stocker les informations actuelles dans le stockage local. Nous fournissons le statique StorageKey précédemment défini et le Model objet.

Maintenant, construisons et exécutons l’application.

Lorsque nous entrons des données dans le formulaire, nous devrions être en mesure de voir les informations stockées dans le stockage local. Nous pouvons vérifier qu’en ouvrant le outils de développeur dans le navigateur et naviguer vers l’onglet Application. Dans l’onglet Application, nous sélectionnons le stockage local dans le groupe de stockage.

Dans le ContactForm Clé, nous avons un objet sérialisé avec les valeurs pour les quatre champs d’entrée de cette forme. Cependant, lorsque nous naviguons vers une autre page dans l’application et revenons au formulaire, il est à nouveau vide.

Chargez les données du stockage local lors de la navigation vers le Contact page Suivant. Nous voulons remplacer le OnInitializedAsync Méthode de cycle de vie pour exécuter du code chaque fois que le composant est initialisé.

protected async override Task OnInitializedAsync()
{
    Model = await LoadItem<ContactModel>(StorageKey) ?? new ContactModel();
}

L’implémentation est simple, utilise le LoadItem méthode que nous avons précédemment implémentée et fournit le StorageKey comme son seul argument.

Maintenant, construisons et exécutons l’application.

Vous pouvez désormais saisir des valeurs dans le formulaire, naviguer d’une page à une autre et revenir plus tard et continuer à remplir le formulaire sans perdre aucune information.

Les avantages de l’utilisation du stockage local pour l’état d’application temporaire

L’un des avantages de l’utilisation du stockage local pour cette tâche est le évolutivité.

Cette technique évolue avec le nombre d’utilisateurs car les informations sont stockées sur le client au lieu du serveur. Il soulage le serveur et enregistre les coûts d’alimentation et de stockage du processeur dans des environnements à grande échelle.

Un autre avantage pourrait être sécurité des données ou protection des données. Bien que nous ayons souvent des mesures pour chiffrer les données au repos sur le disque ou pendant le transport, nous ne voulons pas que ces mécanismes exacts appliqués au stockage temporaire, tels que l’état d’application temporaire, car cela crée des frais généraux coûteux.

En laissant les données temporaires sur le client, nous n’avons pas ce problème dans la plupart des situations.

Qu’en est-il du serveur Blazor?

Dans cet article, nous nous sommes concentrés sur Blazor WebAssembly, car nous pouvons appeler directement JavaScript interopr à partir de Blazor WebAssembly sans aucune boucle client / serveur.

Avec Blazor Server, nous pouvons également utiliser les API de stockage locales, mais nous avons besoin d’un aller-retour pour accéder au stockage local du client.

Indice: Un autre article intitulé Accéder au stockage du navigateur dans les applications Web Blazor dans le Bases du blazor La série utilise le ProtectedBrowserStorage Classe, un bon moyen d’implémenter l’accès au stockage local dans les applications du serveur Blazor.

Cependant, dans la plupart des scénarios de serveur Blazor où le code s’exécute, je préfère utiliser d’autres techniques pour stocker temporairement l’état d’application sur le serveur au lieu du client.

Conclusion

Dans cet article, nous avons appris les principes fondamentaux de la façon de stocker l’état d’application temporaire, comme l’entrée de formulaire, dans le stockage local, une API du navigateur standard.

Des parties de la mise en œuvre, comme le StoreItem et LoadItem Les méthodes peuvent être extraites dans un service et réutilisées pour plusieurs composants.

Nous pourrions étendre cet exemple et utiliser la même technique pour implémenter des scénarios avancés, tels que le maintien des flux de travail côté client sans perdre des informations lorsque l’utilisateur quitte l’application ou les coupes d’alimentation et l’utilisateur se poursuit plus tard.

Si vous voulez en savoir plus sur le développement du blazor, regardez mon Cours crash gratuit du blazor sur YouTube. Et restez à l’écoute du blog Telerik pour en savoir plus Bases du blazor.