Le candidat de la version .NET 10 s’appuie sur une promesse précoce

Le premier candidat à la version pour .NET 10 offre peu de surprises, améliore l’état des composants persistants et offre des mesures plus utiles.

Nous sommes en septembre, ce qui ne peut signifier qu’une chose: c’est le temps candidat de la libération .NET!

.NET 10 RC1 a atterri, et avec lui, quelques améliorations intéressantes de dernière minute.

État persistant

Nouveau dans .net 10 est le PersistentState attribut. Il s’agit d’une version renommée de l’attribut qui a expédié les versions de prévisualisation .NET 10 antérieures. Au revoir SupplyParameterFromPersistentComponentState. Nous vous connaissions à peine.

Mais ce n’est pas seulement un changement de nom. L’attribut a un nouveau comportement subtil, particulièrement pertinent si vous utilisez une navigation améliorée.

Tout d’abord, un récapitulatif rapide.

Si vous appliquez le PersistentState Attribut aux données de votre composant, deux choses se produiront.

1. L’État sera persisté lors du premier rendu, puis réutilisé pour les rendus ultérieurs. Cela signifie que si vous prenez vos composants, les données récupérées pendant la prétention sont ensuite réutilisées lorsque le composant rende à nouveau (en utilisant l’un des modes de rendu interactifs de Blazor).
2. Si vous utilisez le mode de rendu de serveur interactif, toutes les données marquées de cet attribut seront persistées lorsque le circuit sous-jacent sera expulsé. Ainsi, vos utilisateurs pourraient perdre leur connexion, se reconnecter à un nouveau circuit, mais garder leur état persistant.

Joue maintenant bien avec une navigation améliorée

Le grand changement dans RC1 est la façon dont tout cela fonctionne lorsque vous utilisez une navigation améliorée. La navigation améliorée est un moyen utile de fournir une atmosphère «semblable à un spa» pour vos applications Blazor.

Avec une navigation améliorée, lorsqu’un utilisateur suit un lien qui se achemine vers un composant de rasoir dans votre application, Blazor interceptera la navigation, publie un fetch Demandez, récupérez le nouveau contenu de la page, puis le répartissez dans le DOM existant.

Cela rend une expérience plus fluide et évite de recharger toute la page alors qu’une seule partie de celle-ci a réellement changé. Vous rencontrerez cela si votre application est configurée pour Par interactivité de page / composant.

Par exemple, prenez cette version légèrement modifiée de la célèbre page Blazor «Data Mether».

@page "/weather"
@rendermode InteractiveServer

<PageTitle>Weather</PageTitle>

<h1>Weather</h1>

@code {
    
    public WeatherForecast[]? Forecasts { get; set; }

    protected override async Task OnInitializedAsync()
    {
        if (Forecasts == null)
        {
            
            await Task.Delay(500);

            var startDate = DateOnly.FromDateTime(DateTime.Now);
            var summaries = new[] { "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching" };
            Forecasts = Enumerable.Range(1, 5).Select(index => new WeatherForecast
            {
                Date = startDate.AddDays(index),
                TemperatureC = Random.Shared.Next(-20, 55),
                Summary = summaries[Random.Shared.Next(summaries.Length)]
            }).ToArray();
        }
    }   
}

Lorsqu’un utilisateur se rendra à cette page dans votre application (ce qui signifie qu’il a commencé sur une autre page, puis a suivi un lien vers celui-ci), il finira probablement par utiliser une navigation améliorée.

Mais cela ne sera pas super parce qu’ils verront un ensemble de données météorologiques, puis un «flash», suivi de différentes données météorologiques.

C’est grâce à la prétention.

Lorsque la nouvelle page est demandée, Blazor rend votre composant une fois sur le serveur, renvoie ce HTML initial au navigateur, puis fait tourner le mode serveur interactif et rend à nouveau le composant.

Le résultat est un flash visible lorsque les données initiales sont affichées, puis le deuxième ensemble de données est affiché lorsque le composant commence à s’exécuter de manière interactive.

Comme vous pouvez le voir ici, il y a un appel à récupérer les données météorologiques pendant la prétention et une seconde pendant le rendu interactif.

Maintenant c’est précisément ce PersistentState est conçu pour réparer.

Nous pouvons décorer le Forecasts propriété avec le PersistentState attribut. En théorie, cela signifie que les données initiales seront persistées (pendant la prétention) puis réutilisées lors du deuxième rendu (interactif).

@code {
    
    [PersistentState]
    public WeatherForecast[]? Forecasts { get; set; }
    
    
    
}

Mais il s’avère que cela ne fonctionne pas avec une navigation améliorée. Lorsque les utilisateurs naviguent en interne (dans votre application), une navigation améliorée sera utilisée et ils verront toujours que «flash» lorsque les données sont récupérées, puis remontent à nouveau.

Alors qu’est-ce qui donne?

Eh bien, la nouvelle valeur par défaut dans .NET 10 est que l’état des composants persistants ne sera pas appliqué pour les composants interactifs lors de la navigation améliorée.

Il s’agit d’éviter des drames si l’utilisateur finit par naviguer vers la même page où il a déjà sur elle et a des données qu’il souhaite conserver, par exemple sous un formulaire. Dans ce cas, ils ne veulent probablement pas que leurs valeurs de formulaire soient remplacées par l’état des composants persistants.

Mais il existe un moyen de contourner cela et d’avoir un travail d’état persistant comme on pourrait s’y attendre (pour des données comme celle-ci, que l’utilisateur ne change pas).

Nous pouvons définir AllowUpdates = true sur [PersistentState] attribut.

@code {
    
    [PersistentState(AllowUpdates = true)]
    public WeatherForecast[]? Forecasts { get; set; }
    
    
    
}

Cela indique à Blazor que nous sommes heureux que l’état persistant soit utilisé pendant une navigation améliorée.

Lorsqu’un utilisateur navigue vers cette page météorologique, nous voulons que les données qui sont récupérées pendant la prétention soient appliquées lorsque le composant se rend une deuxième fois (rendu de manière interactive).

Avec cela, le «flash» disparaît et nous obtenons une seule version des données.

Notez que les données persistantes sont généralement sérialisées (à l’aide de JSON) et incluses dans le HTML rendu pour le préender initial, puis remontent au composant lorsqu’il tourne dans l’un des modes de rendu interactifs.

Plus de contrôle sur l’état persistant

En plus d’activer l’état persistant lors de la navigation améliorée, nous obtenons également un contrôle plus fin sur la façon dont l’état persistant est appliqué en général.

Rappelez-vous comment Blazor va maintenant (à partir de .NET 10) tenter de restaurer l’état persistant lors de la reconnexion d’un nouveau circuit sur le serveur?

Si vous décidez que vous ne voulez pas que cela se produise, vous pouvez désactiver ce comportement en utilisant le nouveau RestoreBehavior paramètre.

@code {
    [PersistentState(RestoreBehavior = RestoreBehavior.SkipLastSnapshot)]
	public WeatherForecast[]? Forecasts { get; set; }
}

Par défaut, lorsqu’un utilisateur perd sa connexion et que Blazor les relie à un nouveau circuit, Blazor prendra les données météorologiques qu’il avait, la persistent lorsque le circuit est expulsé et le restaurera sur le nouveau circuit.

Du point de vue de l’utilisateur, ils ne remarqueront aucun changement. Les données météorologiques qu’ils avaient avant d’être déconnectées seront les mêmes données météorologiques qu’ils voient sur la page après leur reconnexion.

Mais quand tu réglé RestoreBehavior à SkipLastSnapshotl’état persistant ne sera pas restauré pendant la reconnexion.

Au lieu de cela, de nouvelles données météorologiques seront récupérées et l’utilisateur verra les données changer dans l’interface utilisateur lorsque son navigateur se reconnecte au serveur.

Alternativement, vous pouvez être heureux que l’état persistant soit utilisé pendant la reconnexion, mais ne voulez pas qu’il soit utilisé entre la prétention et le rendu interactif. Dans ce cas, vous pouvez définir RestoreBehavior à SkipInitialValue.

@code {
    [PersistentState(RestoreBehavior = RestoreBehavior.SkipInitialValue)]
    public WeatherForecast[]? Forecasts { get; set; }    
}

Dans ce scénario, disons qu’un utilisateur frappe directement cette page météo lors de la visite de votre application. Avec SkipInitialValueBlazor n’essaiera pas de partager le Forecasts Données entre la prétention et le rendu interactif ultérieur.

Ce qui signifie que, pour cette première charge, nous sommes de retour au flash lorsque les données sont chargées une fois, puis chargées à nouveau pendant le deuxième rendu.

Mais, le Les données persistantes seront utilisées lorsque l’utilisateur perdra sa connexion et se reconnecte.

Clair? Moi non plus!

Essayons de mettre tout cela dans une table pour voir si cela clarifie les choses.

Voici les différentes combinaisons d’options et de résultats (combien de fois les données météorologiques sont récupérées) pour un certain nombre de scénarios différents.

Restore Behavior	Autorisation	Résultat – charge directe de la page	Résultat – Navigation améliorée	Résultat – reconnexion
Valeur de saut	VRAI	Données récupérées deux fois	Données récupérées une fois	Données existantes restaurées
Valeur de saut	FAUX	Données récupérées deux fois	Données récupérées deux fois	Données existantes restaurées
Skiplastsnapshot	VRAI	Données récupérées une fois	Données récupérées une fois	Données réacrées
Skiplastsnapshot	FAUX	Données récupérées une fois	Données récupérées deux fois	Données réacrées

Les trois scénarios montrés sont:

• Chargement de la page directe – Lorsqu’un utilisateur demande directement notre page météo (par exemple en entrant dans l’URL directement dans le navigateur)
• Navigation améliorée – Lorsque l’utilisateur arrive à la page météo par navigation interne (dans l’application, suivant un lien à partir d’une autre page)
• Reconnexion – Lorsque l’utilisateur perd son circuit et que Blazor les reconnecte à un nouveau

Le point à retenir ici est que vous pouvez désormais contrôler précisément comment l’état persistant est restauré. (Il faut juste un peu de travail pour déterminer la combinaison dont vous avez besoin pour votre situation spécifique!)

Améliorations de validation

Sur des changements plus simples…

Vous pouvez désormais appliquer des attributs de validation aux classes et aux enregistrements (pas seulement aux propriétés). Cela ouvre la porte à valider des objets complexes avec une logique personnalisée.

Prenez cet exemple (quelque peu artificiel).

[NoBot]
public class UserRegistration
{
    [Required(ErrorMessage = "Username is required")]
    [StringLength(50, MinimumLength = 3, ErrorMessage = "Username must be between 3 and 50 characters")]
    public string? Username { get; set; }

    [Required(ErrorMessage = "Email is required")]
    [EmailAddress(ErrorMessage = "Please enter a valid email address")]
    public string? Email { get; set; }

    public string? Honeypot { get; set; }
}

Voir le NoBot attribut?

Cela pointe vers un attribut de validation personnalisé, qui peut fonctionner avec l’ensemble de l’objet (pas seulement des champs individuels).

public class NoBotAttribute : ValidationAttribute
{
    protected override ValidationResult? IsValid(object? value, ValidationContext _)
    {
        int botWarningSigns = 0;

        if (value is not UserRegistration registration)
            return new ValidationResult("Invalid registration data.");

        
        if (!string.IsNullOrEmpty(registration.Honeypot))
        {
            botWarningSigns += 1;
        }          

        
        if (!string.IsNullOrWhiteSpace(registration.Username) &&
            !string.IsNullOrWhiteSpace(registration.Email) &&
            registration.Username.Equals(registration.Email, StringComparison.OrdinalIgnoreCase))
        {
            botWarningSigns += 1;
        }

        if(botWarningSigns >= 2){
            return new ValidationResult("Bot-like behavior detected!");
        }

        return ValidationResult.Success;
    }
}

Ainsi, en plus des attributs de validation standard sur les propriétés de la classe, nous avons également écrit une logique personnalisée pour attribuer un «score» basé sur des signes d’avertissement que le formulaire peut avoir été rempli par un bot, alors la validation de l’échec si ce score dépasse un certain nombre.

Il est également possible d’indiquer qu’une propriété devrait sauter la validation.

Par exemple, si vous avez un Address classe qui est réutilisée à quelques endroits et vous ne voulez pas qu’elle soit validée dans l’un de ces cas. Vous pouvez appliquer le [SkipValidation] Attribut à une propriété ou paramètre spécifique, ou à un type.

Nouvelles métriques d’identité de base ASP.NET

Si vous utilisez ASP.NET Core Identity, vous pouvez désormais puiser dans des mesures intégrées pratiques pour les opérations de l’utilisateur et de connexion clés.

Notamment ce qui suit (dans Microsoft.AspNetCore.Identity):

• aspnetcore.identity.user.create.duration
• aspnetcore.identity.user.update.duration
• aspnetcore.identity.user.delete.duration
• aspnetcore.identity.user.check_password_attempts
• aspnetcore.identity.user.generated_tokens
• aspnetcore.identity.user.verify_token_attempts
• aspnetcore.identity.sign_in.authenticate.duration
• aspnetcore.identity.sign_in.check_password_attempts
• aspnetcore.identity.sign_in.sign_ins
• aspnetcore.identity.sign_in.sign_outs
• aspnetcore.identity.sign_in.two_factor_clients_remembered
• aspnetcore.identity.sign_in.two_factor_clients_forgotten

Tous les autres changements ont atterri dans les versions antérieures

.NET 10 est sur la bonne voie en novembre 2025. Si c’est la première fois que vous regardez .net 10, il y a beaucoup plus de changements non couverts ici, qui étaient déjà inclus dans les versions de prévisualisation précédents et sont maintenant cuites dans RC1.

Voici quelques-uns des points forts:

• Le script Blazor est maintenant servi comme un atout statique (avec précompression, préchargement et empreinte digitale)
• NavigateTo conserve la position de défilement
• Le modèle d’application Web comprend désormais le balisage, CSS et JS pour le composant d’interface utilisateur de reconnexion du serveur Blazor
• Nouvelles métriques et traces de blazor pour surveiller les performances de vos applications Blazor
• Composant amélioré INTENDU MANILISATEUR (404S)
• Interopérative JavaScript améliorée
• L’état de composant persistant peut être stocké en mémoire ou en cache hybride
• Nouvelles API pour une pause et une reprise des circuits
• Validation des objets imbriqués
• Passkekey Support

Sur la base de cette version, il semble que Blazor dans .NET 10 est fermement sur la bonne voie pour être la version la plus stable et la plus performante de Blazor jusqu’à présent.

Des défis de longue date (notamment sur la façon dont les déconnexions du serveur Blazor sont traités) ont été relevés, les performances améliorées et l’observabilité améliorée (à la fois en développement et en production en utilisant les nouvelles métriques).

RC1 est la première des sorties «Go-Live», et à ce stade, il semble peu probable que des changements majeurs n’atterriront pas d’ici la libération RTM en novembre.

---

Voir plus de détails sur .NET 10 dans nos mises à jour précédentes: