Fermer

août 8, 2024

Les dernières versions préliminaires de .NET 9 apportent des améliorations tant attendues à Blazor

Les dernières versions préliminaires de .NET 9 apportent des améliorations tant attendues à Blazor


La gestion améliorée des erreurs pour les connexions perdues au serveur Blazor est à l’honneur alors que .NET 9 prend forme avant sa sortie de novembre.

Les travaux sur Blazor et .NET 9 se poursuivent avant sa date de sortie de novembre 2024.

Après les changements radicaux apportés à .NET 8, cette version est en passe d’atténuer certains des aspérités de Blazor. Voici les changements notables publiés dans les aperçus 5 et 6.

Vous pouvez télécharger le dernière version (aperçu) de .NET 9 ici.

Compression et meilleure mise en cache des ressources Web statiques

Dans .NET 8, vous pouvez déposer un fichier statique (par exemple, un fichier CSS) dans votre wwwroot dossier et référencez-le dans votre composant, comme ceci :

App.razor

<head>
	<link href="css/app.css" rel="stylesheet"/>    
</head>

Cela fonctionne très bien, à l’exception de quelques problèmes insignifiants.

Premièrement, le fichier est servi non compressé par défaut. Cela signifie que vos utilisateurs doivent télécharger un ou plusieurs fichiers potentiellement volumineux lorsqu’ils visitent votre application pour la première fois. Le fichier sera alors mis en cache par votre navigateur, mais cela introduit un nouveau problème.

Lorsque vous mettez ensuite à jour le fichier (par exemple, en y ajoutant de nouveaux styles s’il s’agit d’une feuille de style), il n’existe aucun moyen simple de garantir que vos utilisateurs obtiennent la dernière version. Si leur navigateur a déjà mis en cache la version précédente, ils y restent, même si un fichier mis à jour est disponible.

Il existe différents hacks que vous pouvez utiliser pour contourner ce problème, notamment l’ajout d’un paramètre de chaîne de requête arbitraire lorsque vous référencez l’actif (ce qui incitera le navigateur à supposer qu’il s’agit d’un nouveau fichier). Mais ces hacks sont manuels et sujets aux erreurs.

.NET 9 Preview propose une nouvelle API pour gérer les ressources Web statiques, appelée MapStaticAssets.

Cela peut généralement remplacer l’ancien UseStaticFiles dans ton Programme.cs fichier, et fait quelques choses:

  • Compresse les ressources Web statiques en utilisant gzip pendant le processus de construction de votre application et brotli pendant la publication (pour réduire davantage la taille du téléchargement).
  • Définit les Etags pour le fichier basé sur une chaîne codée en Base64 d’un hachage SHA-256 du contenu.
  • Génère des versions avec empreintes digitales des ressources Web statiques lorsque l’application est publiée.

Avec MapStaticAssets les versions compressées de vos ressources statiques seront nettement plus petites que les originales (jusqu’à 93 % plus petites dans certains cas).

L’ETag d’un actif sera généré en fonction du contenu du fichier.

De plus, un nom de fichier unique sera généré, également basé sur le contenu du fichier, de sorte que le navigateur considère une nouvelle version comme un fichier entièrement nouveau (qu’il doit télécharger, plutôt que d’essayer de le servir à partir du cache).

Pour référencer un actif avec empreinte digitale, vous pouvez utiliser le Assets propriété dans vos composants.

<link rel="stylesheet" href="https://www.telerik.com/blogs/@Assets["site.css"]" />

Sous le capot, cela sera résolu par le nom de fichier unique de la version actuelle de ce fichier (en fonction de son contenu).

Prenons cet exemple, où nous référençons un certain nombre de feuilles de style en utilisant le nouveau @Assets propriété.

<head>
    <link href="https://www.telerik.com/blogs/@Assets["css/bootstrap/bootstrap.min.css"]" rel="stylesheet"/>
    <link href="https://www.telerik.com/blogs/@Assets["css/app.css"]" rel="stylesheet"/>
    <link href="https://www.telerik.com/blogs/@Assets["BlazorDemoApp.styles.css"]" rel="stylesheet"/>
</head>

Exécutez ceci, inspectez-le dans le navigateur et vous verrez des noms de fichiers uniques pour chaque fichier :

<link href="css/bootstrap/bootstrap.min.bpk8xqwxhs.css" rel="stylesheet">
<link href="css/app.qbqo6dzkt5.css" rel="stylesheet">
<link href="BlazorDemoApp.jibil5dzda.styles.css" rel="stylesheet">

Ceci, ainsi que ces ETags correctement définis, permettront au navigateur d’utiliser avec plaisir la version mise en cache d’un actif jusqu’à ce que vous publiiez une version modifiée, auquel cas le navigateur récupérera (et mettra en cache) automatiquement la nouvelle version.

UX de reconnexion au serveur Blazor amélioré

Si vous avez exécuté une application Blazor Server en production, vous avez sans aucun doute rencontré le problème où vos utilisateurs perdent la connexion au serveur et se retrouvent face à un message d’erreur inquiétant.

Le problème vient du fait que Blazor Server repose sur la possibilité de se connecter à un circuit SignalR sur le serveur.

Dans les versions précédentes de .NET, toute interruption de cette connexion entraînait un message d’erreur et l’utilisateur était invité à recharger l’application pour continuer.

Dans .NET 9, Blazor tentera désormais de se reconnecter au serveur en utilisant une stratégie d’attente exponentielle. Cela signifie qu’il tentera de se reconnecter rapidement plusieurs fois avant d’augmenter progressivement le délai entre les tentatives.

Alternativement, si un utilisateur accède à une application avec un circuit déconnecté (par exemple parce qu’il ouvre un onglet de navigateur existant pour votre application), la tentative de reconnexion aura lieu immédiatement.

Dans le cas où la connexion est rétablie avec le serveur mais que le serveur a déjà libéré le circuit SignalR, l’application s’actualisera automatiquement.

Ensemble, ces changements rendent beaucoup moins probable que vos utilisateurs soient interrompus et obligés de recharger l’intégralité du site lorsque des problèmes de réseau intermittents surviennent ou après une absence prolongée avant de revenir sur votre site.

Pour refléter ces changements, l’interface utilisateur de reconnexion par défaut est désormais plus « conviviale », affichant un message « Rejoindre le serveur… » et un indicateur de progression lorsque la reconnexion est tentée.

Interface utilisateur de Blazor Interactive Server lors de la liste de connexions

Maîtrisez vos modes de rendu

L’un des changements les plus importants introduits dans .NET 8 est la possibilité d’exécuter votre composant dans l’un des différents modes de rendu : rendu statique côté serveur, serveur interactif, WASM interactif et Auto interactif.

Au-delà de cela, si vous utilisez le pré-rendu, votre composant peut être rendu sur le serveur une minute, puis dans le navigateur la minute suivante (pré-rendu d’abord, puis rendu à nouveau dans le navigateur si vous utilisez les modes WASM interactif ou Auto).

Cela présente un défi lorsque vous avez du code que vous souhaitez uniquement exécuter dans le navigateur (pas sur le serveur, par exemple lors du pré-rendu) ou lorsque vous avez besoin d’un code différent à exécuter en fonction du mode de rendu en cours.

Pour résoudre ce problème, vos composants ont désormais accès à un RendererInfo propriété qui expose deux propriétés :

  • RendererInfo.Name
  • RendererInfo.IsInteractive

Name vous dira où votre composant est actuellement en cours d’exécution (Static, Server, WebAssembly ou, si vous utilisez .NET MAUI, WebView).

IsInteractive indique si le composant est actuellement exécuté de manière interactive (et non Static).

Cette dernière est utile pour détecter efficacement si votre composant est actuellement en pré-rendu, notamment lorsqu’il est combiné avec une autre nouvelle propriété : AssignedRenderMode.

AssignedRenderMode vous indique dans quel mode de rendu votre composant finira par s’exécuter.

Par exemple, si votre composant est en pré-rendu, AssignedRenderMode vous indiquera le mode de rendu que votre composant utilisera après le pré-rendu.

Combinés, ces indicateurs donnent une indication utile sur la manière dont votre composant est rendu, vous permettant d’exécuter du code dans différents scénarios (par exemple, désactiver les entrées pendant le pré-rendu lorsque vous savez que le composant est sur le point d’être rendu de manière interactive).

Voici un composant qui montre les nouvelles propriétés :

<h3>Render Info</h3>
<ul>
    <li>Name: @RendererInfo.Name</li>
    <li>Is Interactive: @RendererInfo.IsInteractive</li>
    <li>Assigned Render Mode: @AssignedRenderMode</li>
</ul>

Voici ce composant rendu à l’aide de .NET InteractiveWebAssembly mode de rendu.

<Info @rendermode="@InteractiveWebAssembly"/>

Par défaut, Blazor pré-rend les composants, donc lors du premier chargement, nous voyons ceci :

Informations de rendu pour le composant en cours de pré-rendu

Puis, après une courte attente, le composant est à nouveau rendu, cette fois sur le client :

Rendre les informations pour le composant exécuté de manière interactive dans Web Assembly

Sérialiser et partager automatiquement l’état d’authentification entre le serveur et le client

Dans .NET 8, vous pouvez lancer un projet avec l’authentification gérée via Comptes individuels.

Voici ce qui se passe lorsqu’un utilisateur fait une demande sur votre site avec l’authentification activée.

Blazor Auth Flow montrant la sérialisation et la désérialisation de l'état d'authentification

Votre application gère l’authentification sur le serveur.

Une fois que le serveur a authentifié l’utilisateur, il peut émettre des cookies, des jetons, etc. et créer un AuthenticationState objet.

Ce AuthenticationState L’objet contient des détails sur l’état d’authentification de l’utilisateur, y compris son nom et son rôle, et permet aux différents composants d’authentification de Blazor de fonctionner.

Mais que se passe-t-il si vous souhaitez exécuter des composants à l’aide de WebAssembly ?

Pour lire cet état d’authentification dans ces composants, vous avez besoin d’un moyen de prendre le AuthenticationState objet (qui existe sur le serveur) et rendez-le disponible à votre composant lorsqu’il est exécuté via WebAssembly dans le navigateur.

Dans le modèle de projet par défaut, ceci est réalisé via un code passe-partout qui sérialise le AuthenticationState objet et l’envoie dans le code HTML renvoyé au navigateur.

Blazor s’exécutant sur le client (navigateur) lit et désérialise ensuite cet état d’authentification intégré.

Mais le code passe-partout pour y parvenir est assez détaillé et contient beaucoup de code à implémenter (ou à copier) vous-même si vous souhaitez implémenter l’authentification dans un autre projet.

Depuis la dernière version de .NET 9 Preview, vous pouvez désormais activer automatiquement cette sérialisation et désérialisation de AuthenticationState dans ton Programme.cs des dossiers.

Sur le serveur :

builder.Services.AddRazorComponents()
    .AddInteractiveWebAssemblyComponents()
    .AddAuthenticationStateSerialization();

Et sur le client :

builder.Services.AddAuthorizationCore();
builder.Services.AddCascadingAuthenticationState();
builder.Services.AddAuthenticationStateDeserialization();

Cela permet d’obtenir le même résultat (voir schéma ci-dessus) sans inclure le code de sérialisation/désérialisation dans votre projet.

En résumé

Les dernières versions préliminaires de .NET 9 incluent des modifications qui facilitent l’utilisation des modes de rendu introduits dans .NET 8.

Les améliorations apportées à la gestion statique des actifs aident vos fichiers à être servis de manière rapide et performante.

Le problème de longue date de la déconnexion brutale des utilisateurs de vos applications Blazor Server retient enfin l’attention, avec une meilleure gestion des déconnexions et une UX améliorée.

Enfin, certains codes passe-partout détaillés sont supprimés de vos projets lors du partage de l’état d’authentification entre le serveur et le client.

.NET 9 sera lancé en novembre 2024.

Le meilleur outil 2023 pour ta croissance Instagram !



Source link