.NET 10 Aperçu version 6 s’attaque au problème de l’état perdu de Blazor Server

La dernière version d’aperçu de .NET 10 apporte une solution au problème difficile des connexions perdues, ce qui entraîne un état de composant perdu.

.NET 10 Aperçu 6 offre quelques améliorations clés pour Blazor. Voici un aperçu des changements les plus notables (et un en particulier qui pourrait bien résoudre le problème le plus long de Blazor Server).

Blazor Server State Persistance

Il s’agit peut-être de la plus grande nouvelle de l’aperçu 6 pour Blazor (si vous utilisez le mode Server Interactive). Il est désormais possible de persister votre état de composant, lorsque vous utilisez Blazor Server, d’une manière qui signifie que l’utilisateur peut récupérer cet état, même s’il perd la connexion au serveur.

Avant cette version, si une connexion était perdue (pour une raison quelconque, y compris parce que l’utilisateur était «inactif» sur votre site pendant une période donnée), alors Blazor expulserait le circuit sur le serveur (pour gérer les ressources) après une courte période de grâce.

Plus précisément, il tiendrait l’état pendant un certain temps (généralement quelques minutes), mais si l’utilisateur n’avait toujours pas été actif à cette époque, cela expulserait le circuit et perdrait l’état dans le processus.

À partir de .NET 9, Blazor a tenté de rafraîchir automatiquement la page (pour essayer de recommencer avec un nouveau connexion / circuit). Mais même si cela réussissait, vos utilisateurs perdraient leur état de composant.

Ce qui était probablement très ennuyeux si vous travailliez sur une forme et décidiez d’aller déjeuner, pour revenir plus tard et constater que l’état de la forme avait été perdu!

À partir de .NET 10 Aperçu 6, il est désormais possible de faire expulser l’état de composant Blazor Server Persist juste avant l’expulsion du circuit et de restaurer cet état lorsque l’utilisateur redevient actif (à quel point une nouvelle connexion sera établie).

Du point de vue de l’utilisateur, ils peuvent sauter directement et continuer où ils s’étaient arrêtés.

Il fonctionne automatiquement et pour indiquer que vous déclarez délibérément un état persistant. La façon la plus simple de le faire est d’utiliser un nouvel attribut déclaratif pratique de .NET 10:

Comptoir

@code {

    [SupplyParameterFromPersistentComponentState]
    int CurrentCount { get; set; } = 0;

    private void IncrementCount()
    {
        CurrentCount++;
    }

}

Le [SupplyParameterFromPersistentComponentState] L’attribut (à renommer à quelque chose de moins verbeux imminente) dit à Blazor de persister CurrentCount.

Ceci est utile pour deux scénarios:

1. Prérencier (permet d’utiliser exactement le même état pour la prétention et le rendu interactif)
2. Pour persister l’état lorsque le circuit est expulsé

Ce deuxième comportement est le nouveau dans l’aperçu 6 et se produira automatiquement.

Avec ce seul changement, les utilisateurs peuvent maintenant cliquer sur le bouton pour incrémenter le compteur à un nombre (disons 10), puis prendre aussi longtemps une pause déjeuner qu’ils le souhaitent. À leur retour, le client se reconnectera au serveur, à quel point une nouvelle connexion sera établie et un nouveau circuit sera créé sur le serveur.

Grâce à l’état persistant, le nouveau circuit aura le même état que l’ancien état (expulsé), donc le compteur montrera toujours la valeur 10.

Stocker en mémoire ou cache hybride

Bien sûr, vous vous demandez peut-être où l’État est persisté.

Par défaut, ce sera en mémoire, ce qui signifie qu’un redémarrage de serveur (ou un nouveau déploiement) est susceptible de faire perdre cet état.

Mais si vous configurez votre application pour utiliser un cache hybride, l’état du composant sera persisté à l’aide de cela, ce qui signifie qu’il peut être stocké dans la mémoire et sur un cache distribué. Cela devrait rendre les applications Blazor Server beaucoup plus robustes lorsque vous avez plusieurs instances de votre application en cours d’exécution.

Dans le passé, vous pouvez avoir utilisé des sessions collantes pour vérifier que les demandes du client sont envoyées au même serveur (lors de l’hébergement de plusieurs instances de votre application sur le serveur). Les séances collantes sont encore précieuses, mais l’état de composant persistant lorsqu’il est utilisé avec un cache hybride est un autre moyen de vérifier que les circuits peuvent toujours récupérer les données correctes, quel que soit le serveur qui finit par fonctionner.

API pour la pause et la reprise des circuits

Main dans la main avec ce nouveau comportement vient la capacité de déclencher manuellement des circuits de pause et de reprise.

Supposons que vous décidiez de forcer le problème, et au lieu d’attendre le «délai d’expiration» par défaut de Blazor Server (lorsqu’il décidera qu’un circuit est inactif et peut être expulsé), vous décidez que vous voulez simplement aller de l’avant et en suspendre un circuit vous-même.

Vous pouvez le faire avec un peu de javascript, comme celui-ci par exemple:

document.addEventListener('visibilitychange', ()=> {
    if(document.hidden) {
        Blazor.pause();
    } else {
        Blazor.resume();
    }
});

Cela répond aux changements de visibilité (les onglets de commutation utilisateur) mais pourrait tout aussi facilement par tout événement JavaScript.

Les lignes clés sont les appels à soit pause ou resume Blazor.

Quand tu appelles pauseBlazor ira de l’avant et persistera n’importe quel État signalé pour être persisté. (N’oubliez pas cet attribut déclaratif pratique que nous avons vu plus tôt.) Lorsque vous appelez resumeil restaurera tout état persistant lorsqu’il reprendra le circuit.

En effet, cela signifie que vous pouvez optimiser les performances de Blazor Server en prenant le contrôle de la pause (et de l’expulsion) des circuits, tout en récupérant automatiquement l’état des composants lorsque vous essayez par la suite de reprendre ce circuit.

Validation des objets imbriqués

Dites que vous avez un modèle avec des objets imbriqués, comme ceci:

public class Order
{     
    [Required(ErrorMessage = "Customer information is required")]   
    public Customer Customer { get; set; } = new();
   
    [Required(ErrorMessage = "At least one order item is required")]
    [MinLength(1, ErrorMessage = "Order must contain at least one item")]
    [MaxLength(50, ErrorMessage = "Order cannot contain more than 50 items")]   
    public List<OrderItem> Items { get; set; } = new();
 
    public ShippingInfo? ShippingInfo { get; set; }

    [StringLength(500, ErrorMessage = "Notes cannot exceed 500 characters")]
    public string? Notes { get; set; }
}

Auparavant, seules les propriétés de niveau supérieur seraient validées lors de l’utilisation du DataAnnotationsValidator pour Blazor avec vos formulaires. Il y avait des solutions de contournement, notamment en utilisant un package NuGet séparé de Microsoft pour que la validation fonctionne pour les types imbriqués (comme les informations d’expédition et les articles de commande ici).

.NET 10 corrige cela afin que votre validation de type imbriqué complexe fonctionne hors de la boîte.

Pour opter pour le nouveau système de validation, vous devrez ajouter cette ligne à Program.cs:

builder.Services.AddValidation();

Avec cela, tout formulaire utilisant <DataAnnotationsValidator /> Va également valider vos objets et collections imbriquées.

Préchargement des actifs de Blazor WebAssembly

L’un des défis de l’utilisation de Blazor WebAssembly est le grand téléchargement initial lorsqu’un utilisateur visite pour la première fois votre site. Il existe un certain nombre d’actifs qui doivent être téléchargés pour que Blazor Wasm fonctionne (fichiers Framework, votre code d’application compilé, etc.)

Lorsque vous chargez des actifs comme celui-ci, il est possible d’accélérer le processus en demandant au navigateur de précharger ces ressources. Ainsi, au lieu d’attendre que la page se charge, vérifie, puis téléchargeant toutes les ressources liées une par une, le navigateur peut commencer à télécharger ces actifs liés immédiatement.

Pour utiliser ce préchargement, vous pouvez inclure le nouveau <LinkPreload /> composant de votre application head élément.

<head>
    
    
    <LinkPreload /> 
</head>

Cela changera désormais automatiquement le comportement précharge des actifs.

Sans cette balise, votre application Blazor Wasm se chargerait comme ceci:

1. Analyser le HTML.
2. Découvrir et télécharger blazor.web.js.
3. Ce script découvre et télécharge ensuite les fichiers d’exécution .NET.
4. Télécharge vos assemblées d’application.
5. Enfin, démarrez votre application.

Avec le nouveau <LinkPreload /> Composant, les étapes 3-4 commencent immédiatement lorsque le HTML se charge, accélérant le chargement de WASM et rendant ainsi votre application à la vie plus rapidement du point de vue de l’utilisateur.

Opter pour désactiver les exceptions de navigation

Il y a un problème lors de l’utilisation du rendu statique du serveur. Si vous essayez de naviguer vers un nouvel itinéraire en utilisant NavigationManager.NavigateTovous remarquerez que votre code lance un NavigationException.

Sous le capot, le cadre capture ensuite cette exception pour la convertir en redirection. Cependant, si vous déboguez, il s’agit d’une expérience sous-optimale, car vous verrez le débogueur se casser lorsque cette exception est lancée (même si l’application se comporte comme prévu).

Il y a aussi un effet d’entraînement par lequel n’importe quel code après le NavigateTo L’appel est exécuté dans les modes de rendu interactifs, mais pas dans les scénarios SSR.

.NET 10 a un mode où il ne lancera pas ces exceptions et peut plutôt signaler au rendu qu’une redirection est demandée.

Ce nouveau comportement a été introduit dans une version d’aperçu précédente. Dans Aperçu 6, c’est maintenant «Opt in» via un commutateur AppContext:

AppContext.SetSwitch("Microsoft.AspNetCore.Components.Endpoints.NavigationManager.DisableThrowNavigationException", isEnabled:true);

Passkekey Support

Enfin, si vous créez un nouveau projet Blazor en utilisant Individual Accounts Pour Auth, vous remarquerez une nouvelle fonctionnalité. Les utilisateurs, une fois qu’ils ont configuré leur compte, peuvent désormais ajouter une clé de passe pour leur compte.

Cela signifie qu’ils pourront utiliser des services comme Windows Hello pour se connecter à votre application Blazor (par opposition à la connexion avec Social Auth et / ou un nom d’utilisateur / mot de passe à chaque fois).

En résumé

Blazor Server voit les plus grandes victoires de ce communiqué, avec une expérience considérablement améliorée pour les utilisateurs finaux (plus d’état de perte car ils ont fait une pause déjeuner).

D’autres domaines voient également l’amélioration alors que .NET 10 approche de sa version de prévisualisation finale. (Plus à faire, puis quelques candidats à la sortie, à quel point toutes les nouvelles fonctionnalités devraient être en place et l’accent sera déplacé vers la qualité / les performances.)