.NET 9 se prépare avant sa sortie en novembre 2024. Voici les faits saillants de Blazor jusqu’à présent.
.NET 8 était une version importante pour Blazor, introduisant de nouveaux modes de rendu interactifs et une option permettant de créer des applications Web entières à l’aide du rendu statique côté serveur. Il s’agissait également d’une version LTS (Long Term Support), ce qui signifie qu’elle est entièrement prise en charge par Microsoft jusqu’en novembre 2026.
Microsoft se concentre désormais sur la fourniture d’un ensemble plus restreint de modifications, d’ajustements et d’améliorations pour Blazor dans la prochaine version de .NET 9, prévue pour novembre 2024. Il s’agira d’une version STS (Standard Term Support) avec une prise en charge de 18 mois après le lancement.
Voici quelques-uns des principaux changements apportés à Blazor publiés jusqu’à présent (à partir de l’aperçu 4).
Ajouter des pages SSR statiques aux applications Web interactives Blazor
L’un des changements les plus importants apportés à .NET 8 est la possibilité d’exécuter votre application en utilisant différents modes de rendu.
Vous pouvez choisir d’exécuter vos pages en utilisant rendu statique côté serveuroù le composant est rendu sur le serveur et le HTML brut est renvoyé au navigateur.
Ou vous pouvez opter pour l’un des modes de rendu interactifs (Serveur, WASM ou Auto).
Dans .NET 8, il est possible de configurer l’intégralité de votre application pour qu’elle s’exécute dans un seul mode, globalement. Par exemple, si vous souhaitez que votre application s’exécute en mode serveur interactif. Mais vous êtes alors coincé avec ce mode de rendu interactif pour toutes les pages/composants de votre application.
Dans .NET 9, il sera possible de configurer un composant de page pour qu’il s’exécute à l’aide d’un SSR statique, même au sein d’une application qui est par ailleurs configurée pour s’exécuter de manière interactive.
Cela vaut la peine de dire que c’est quelque chose que vous voudriez éviter dans la plupart des cas. Cela forcera un rechargement complet de la page, ce qui est moins efficace et moins réactif que le même composant exécuté de manière interactive (où Blazor peut être efficace pour récupérer l’interface utilisateur et la corriger dans le DOM du navigateur).
Mais cela sera utile lorsque vous aurez absolument besoin qu’une page spécifique s’exécute de cette façon, par exemple si vous en avez besoin pour lire/écrire des cookies HTTP.
Comment fonctionne généralement le routage pour une application Blazor
Pour comprendre comment cela fonctionne, considérons ceci typique App.razor composant:
<!DOCTYPE html>
<html>
<head>
...
<HeadOutlet @rendermode="InteractiveServer" />
</head>
<body>
<Routes @rendermode="InteractiveServer" />
...
</body>
</html>
Lorsqu’un utilisateur tente de naviguer vers une page spécifique (par exemple, « /counter »), ce composant de niveau supérieur sera rendu. À son tour, cela rendra le Routes composant utilisant le spécifié @rendermode.
Dans ce cas, cela signifie que tout le routage sera géré par notre Routes composant qui est s’exécutant de manière interactive à l’aide du serveur Blazor.
Passage au SSR statique pour les pages individuelles
Pour que cette page de notre application s’exécute à l’aide d’un rendu statique côté serveur, nous avons besoin d’un moyen de forcer cette requête (pour notre page non interactive) à être gérée par un routeur qui s’exécute de manière « non interactive » (en utilisant un SSR statique). ).
Nous pouvons le faire dans .NET 9 en deux étapes :
- Indiquez qu’un composant doit être exclu du routage interactif.
- Modifier App.razor pour utiliser le SSR statique lors du routage vers ce composant.
La première étape consiste à exclure le composant de l’utilisation du routeur interactif de Blazor.
PageToBeRenderedUsingSSR.razor
@attribute [ExcludeFromInteractiveRouting]
En décorant une page avec le ExcludeFromInteractiveRouting attribut, il sera exclu du routage interactif. Cependant, cet attribut en lui-même ne fera pas grand-chose.
Ensuite, nous devons modifier App.razor alors le Routes Le composant utilisera le SSR statique comme mode de rendu pour ce composant.
Voici un exemple, pris à partir des documents officiels:
<!DOCTYPE html>
<html>
<head>
...
<HeadOutlet @rendermode="@PageRenderMode" />
</head>
<body>
<Routes @rendermode="@PageRenderMode" />
...
</body>
</html>
@code {
[CascadingParameter]
private HttpContext HttpContext { get; set; } = default!;
private IComponentRenderMode? PageRenderMode
=> HttpContext.AcceptsInteractiveRouting() ? InteractiveServer : null;
}
Cela apporte un paramètre pour HttpContext.
Nous pouvons alors appeler le nouveau HttpContext.AcceptsInteractiveRouting méthode pour vérifier si la requête actuelle concerne une page qui accepte le routage interactif (en fonction de la ExcludeFromInteractiveRouting attribut).
Si c’est le cas, il reviendra InteractiveServer comme mode de rendu ; sinon ça revient null. null indique que le composant doit être rendu en utilisant SSR statique. Notre Routes Le composant sera ensuite rendu en utilisant le mode de rendu approprié.
Connexions WebSocket plus efficaces pour Blazor Server
Dans .NET 9, vos composants Interactive Server seront désormais activer la compression pour les connexions WebSocket sous-jacentes par défaut.
Cela entraînera une utilisation réduite de la bande passante (moins de données transmises et reçues du serveur). En conséquence, vous devriez constater un transfert de données plus rapide et une latence plus faible lors de l’interaction avec ces composants.
Cependant, l’utilisation de la compression avec les connexions WebSocket augmente la vulnérabilité d’une application aux attaques par canal secondaire (où un attaquant peut attaquer le cryptage TLS de la connexion). Si vous voulez comprendre pourquoi c’est le cas, consultez les documents officiels ici pour interagir avec ces composants).
Pour contrer ce risque de sécurité accru, ces composants spécifieront également un frame-ancestors Politique de sécurité du contenu (CSP) de self.
Les CSP constituent une fonctionnalité de sécurité importante qui spécifie quelles sources de contenu peuvent être chargées et exécutées par une page Web. Ici le frame-ancestors CSP signifie que le composant ne peut être intégré que dans un iframe avec la même origine que l’application servant le composant avec la compression activée.
Cette restriction empêche quelqu’un d’intégrer une page de votre application Blazor dans un iframe sur un autre site, réduisant ainsi les chances de réussite d’une attaque par canal secondaire.
Bien entendu, si vous souhaitez désactiver cette compression, vous pouvez :
.AddInteractiveServerRenderMode(o => o.ConfigureWebSocketOptions = null)
Vous pouvez également renforcer davantage la sécurité en bloquant toute intégration dans un iframe.
.AddInteractiveServerRenderMode(o => o.ContentSecurityFrameAncestorsPolicy = "'none'")
Injection de constructeur
Il existe quelques endroits où vous pouvez placer le code de vos composants C# Razor.
Vous pouvez utiliser un @code {} bloquer dans le fichier .razor lui-même.
Salutation.razor
<h2>Hello @name</h2>
@code {
private string name = "Alice";
}
Alternativement, vous pouvez choisir de déclarer une classe distincte (dans ce cas en utilisant le partial mot-clé).
Salutation.razor.cs
public partial class Greeting(){
private string name = "Alice";
}
Avec cette dernière approche, vous avez toujours pu injecter des dépendances à l’aide de l’injection de propriétés.
Disons, par exemple, que nous voulons injecter et utiliser NavigationManager (pour naviguer par programme vers une autre page).
Salutation.razor.cs
using Microsoft.AspNetCore.Components;
namespace BlazorExperiments.Components.Pages;
public partial class Greeting
{
private string name = "Alice";
[Inject] protected NavigationManager NavMan { get; set; }
private void NavigateHome()
{
NavMan.NavigateTo("https://www.telerik.com/");
}
}
Cela injecte une instance de NavigationManager via le NavMan propriété (puis l’invoque depuis le NavigateHome méthode).
Dans l’interface utilisateur, nous pouvons appeler NavigateHome pour déclencher la navigation.
Salutation.razor
@page "/greeting"
@rendermode InteractiveServer
<h2>Hello @name</h2>
<button @onclick="NavigateHome">Go Home</button>
L’exemple ci-dessus fonctionnera dans .NET 8 (et les versions antérieures de .NET).
Désormais, dans .NET 9, il existe une nouvelle option pour injecter des dépendances via l’injection de constructeur :
public partial class Greeting(NavigationManager navMan)
{
private string name = "Alice";
private void NavigateHome()
{
navMan.NavigateTo("https://www.telerik.com/");
}
}
Cela utilise les constructeurs principaux de C# 12, mais vous pouvez bien sûr utiliser ici également un constructeur standard.
Prise en charge des événements de composition
Vous pourriez être pardonné de ne pas connaître les événements de composition (je ne le savais pas !), mais il s’avère qu’ils sont importants lors de la gestion des méthodes de saisie de caractères internationales. Des langues comme le chinois, le japonais et le coréen comportent de nombreux ensembles de caractères (des milliers) qui ne sont pas facilement mappés à une disposition de clavier standard.
Pour ces langues, vous pouvez utiliser un éditeur de méthode d’entrée (IME). Un IME permet aux utilisateurs de saisir des séquences de touches qui sont ensuite converties en caractères souhaités. Il s’agit d’un processus de composition en plusieurs étapes, dans lequel l’utilisateur démarre la composition, sélectionne différents personnages, puis finalise la saisie.
Les événements de composition sont déclenchés lorsque l’IME démarre une nouvelle session de composition, met à jour la session avec une nouvelle entrée et finalise finalement la session de composition.
Pour gérer correctement les entrées utilisateur dans ces scénarios, vous devez être capable de faire la distinction entre les événements clés réguliers et ceux qui font partie d’une session de composition.
.NET 9 introduira un KeyboardEventArgs.IsComposing propriété pour indiquer si un événement clavier fait partie d’une session de composition.
Il sera alors possible de l’utiliser pour déclencher la logique appropriée à vos composants spécifiques.
OverscanCount pour QuickGrids
Enfin, nous avons un nouveau OverscanCount paramètre pour le QuickGrid composant.
QuickGrid est un moyen pratique d’afficher rapidement les données dans vos composants Blazor.
Il prend également en charge virtualisationoù vous pouvez charger une quantité initiale de données, puis, à mesure que l’utilisateur fait défiler les données, en récupérer davantage et les charger dans le code HTML existant.
Cela se traduit par un défilement apparemment infini pour l’utilisateur, sans faire exploser votre navigateur en tentant de charger potentiellement des milliers, voire des millions, de lignes de données en même temps.
Pour réduire le nombre de rendus, QuickGrid restitue généralement un certain nombre d’éléments supplémentaires avant et après la région visible.
Supposons que l’utilisateur visualise les lignes 20 à 30. QuickGrid affichera également un certain nombre de lignes avant la ligne 10 et après la ligne 30.
Le nombre de lignes est déterminé par le OverscanCount. Si la OverscanCount est défini sur 5, dans notre exemple, QuickGrid afficherait les lignes 15 à 35. Il n’a alors pas besoin d’être restitué jusqu’à ce que l’utilisateur fasse défiler jusqu’à (ou au-dessus) la ligne 14 ou jusqu’à (ou au-delà) la ligne 36.
L’inconvénient d’un nombre important de surbalayages est qu’il peut entraîner une augmentation des temps de chargement initiaux. L’astuce consiste donc à trouver un équilibre basé sur vos données et une expérience optimale pour l’utilisateur.
Petites améliorations de la qualité de vie
Voilà donc une poignée d’améliorations petites mais utiles et importantes pour Blazor dans .NET 9.
Après les grands changements apportés à .NET 8, il n’est peut-être pas surprenant que nous constations des améliorations plus modestes et progressives dans .NET 9.
Cela dit, il reste quelques éléments importants à venir selon la feuille de route .NET 9, notamment :
- Améliorations à état persistant lors de l’utilisation de la navigation améliorée
- Méthode simplifiée (déclarative) pour état persistant entre le prérendu et le rendu interactif
- Inclusion de Authentification de la plateforme d’identité Microsoft en option dans le modèle d’application Web Blazor
- Logique de reconnexion améliorée pour le serveur Blazor
Pour l’instant, .NET 9 Preview 4 atténue certains des bords les plus rugueux de Blazor.
À partir de là, nous pouvons nous attendre à quelques versions préliminaires supplémentaires, à quelques versions candidates, puis .NET 9 sera disponible en novembre 2024.
Source link