Fermer

décembre 3, 2024

Choses à savoir avant de migrer votre application Blazor vers .NET 9

Choses à savoir avant de migrer votre application Blazor vers .NET 9


Vous envisagez de passer à .NET 9 pour le développement Blazor ? Voici quelques éléments clés à surveiller.

.NET 8 était une version sismique pour Blazor, avec de nouveaux modes de rendu et paradigmes pour la création d’applications Web.

.NET 9, en comparaison, prend une touche plus légère. À l’exception de quelques ajustements mineurs ici et là, la surface de l’API de Blazor reste en grande partie inchangée. Au lieu de cela, cette version apporte quelques améliorations dans des domaines clés et atténue certains des aspérités de .NET 8.

Voici un guide rapide des principales modifications et de ce que vous pouvez faire pour commencer à utiliser .NET 9 dès aujourd’hui.

Mettez à niveau votre application Blazor vers .NET 9

Les changements les plus notables pour Blazor dans .NET 9 incluent :

  • Nouvelle gestion des fichiers statiques
  • Améliorations du routeur
  • Sérialisation automatique de l’état d’authentification
  • RendererInfo pour voir quel mode de rendu vos composants utilisent
  • Amélioration de l’expérience utilisateur de reconnexion au serveur Blazor

Vous pouvez en savoir plus sur le nouvelle gestion des fichiers statiques, amélioration de l’expérience utilisateur de reconnexion de Blazor Server et RendererInfo ici.

Améliorez vos projets

Dans la plupart des cas, la mise à niveau de votre projet .NET 8 vers .NET 9 nécessite quelques étapes.

D’abord, vous voudrez changer le TargetFramework version de net8.0 à net9.0 dans votre .csproj fichier(s).

<PropertyGroup>
    <TargetFramework>net9.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
</PropertyGroup>

Mettez ensuite à jour toutes les références de package pointant vers .NET 8.

<ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore" Version="9.0.0"/>
    <PackageReference Include="Microsoft.AspNetCore.Identity.EntityFrameworkCore" Version="9.0.0"/>
    <PackageReference Include="Microsoft.EntityFrameworkCore.Sqlite" Version="9.0.0"/>
    <PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="9.0.0"/>
</ItemGroup>

Si vous avez plusieurs projets (par exemple un projet client parce que vous utilisez le mode de rendu WASM interactif), vous souhaiterez également faire la même chose dans ces fichiers de projet.

Gestion des fichiers statiques

Si vous effectuez une mise à niveau à partir d’une version antérieure, vous pouvez choisir de vous en tenir au middleware existant pour gérer les fichiers statiques ou de passer à la nouvelle version.

Dans votre projet existant, vous aurez probablement une ligne comme celle-ci (en Programme.cs) :

app.UseStaticFiles();

Une fois que vous êtes passé à .NET 9, vous pouvez accéder au nouveau middleware d’actifs statiques en le modifiant pour appeler MapStaticAssets().

app.MapStaticAssets();

A ce stade, tout devrait toujours fonctionner comme avant, mais vous pouvez choisir d’utiliser les fonctionnalités de la nouvelle API, notamment :

  • Compression de vos ressources Web statiques
  • Génération automatique d’ETag et prise d’empreintes digitales

Pour que cela fonctionne, vous devrez modifier tous les liens vers des ressources statiques dans votre App.razor déposer.

Supposons que vous ayez des liens existants comme ceux-ci (vers des fichiers CSS dans ce cas) :

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

Cela fonctionne, mais vos actifs liés seront servis non compressés et seront probablement mis en cache par le navigateur.

Il peut être difficile de « détruire » le cache du navigateur. Vous avez probablement constaté cela en pratique lorsque vous déployez une nouvelle version de votre site, après avoir apporté des modifications à vos fichiers CSS, et que vous remarquez que votre application affiche toujours d’anciens styles.

Pour profiter de la compression automatique et des nouveaux mécanismes de contournement du cache, vous devez modifier vos références d’actifs statiques :

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

Notez l’utilisation du nouveau @Assets directif.

Consultez le code source obtenu dans le navigateur et vous verrez des noms de fichiers uniques générés automatiquement pour vos ressources :

<head>     
    <link rel="stylesheet" href="app.nbv275bdso.css" />
    <link rel="stylesheet" href="MyApp.x88yoos200.styles.css" />
</head>

Ceci est votre confirmation que le nouveau middleware d’actifs statiques fonctionne.

Les noms de fichiers uniques changeront automatiquement au moment de la construction lorsque vous publierez votre application avec des ressources mises à jour. Sous le capot, la combinaison de cela et d’ETags correctement définis garantit que le cache du navigateur sert toujours la dernière version.

Notez que cela fonctionne également pour les scripts JavaScript. Par exemple, disons que vous avez un script comme celui-ci :

MonScript.js

function SayHello(){
    console.log("Hello");
}

Vous pouvez modifier votre importation pour utiliser le @Assets directive pour garantir que l’importation utilise la version avec empreinte digitale du script :

App.razor

<head>
	<script src="https://www.telerik.com/blogs/@Assets["myscript.js"]"></script>
    
    <script>
    	
		SayHello();
	</script>
</head>

N’utilisez pas @Asset pour charger le fichier Blazor JS

Attention : il n’est pas possible d’utiliser le nouveau @Asset directive pour importer les scripts du framework Blazor (blazor.*.js).

Apparemment, cela va casser les choses à cause de la façon dont blazor.web.js est servi.

Au lieu de cela, le script Blazor JS doit rester référencé comme il l’est habituellement, dans App.razor.

<body>
<Routes/>


<script src="_framework/blazor.web.js"></script>
</body>
</html>

Mapper les modules JavaScript à l’aide d’ImportMap

Alors que le @Asset La directive fonctionne pour les scripts JavaScript de base, elle ne fonctionne pas pour les modules JavaScript (la manière la plus moderne d’interagir avec JavaScript). Pour cela, vous devez utiliser ImportMap.

Prenez, par exemple, ce module simple.

MonScript.js

function SayHello(){
    console.log("Hello from a module!");
}

export { SayHello };

Nous pouvons importer ce module et invoquer le SayHello méthode comme celle-ci :

App.razor

<head>
    

    <script type="module">
    	import { SayHello } from './myscript.js';
    	SayHello();
    </script>
</head>

Cependant, cela contournerait les avantages du nouveau middleware de fichiers statiques (nous n’obtiendrons pas de contournement du cache ni de compression).

Pour cela, nous devons utiliser le nouveau <ImportMap /> composant.

<head>    
    
	<ImportMap />
</head>

Par défaut, ImportMap détectera tous les modules JS dans votre application, ainsi que d’autres modules de framework importants.

Par exemple, dans un projet Blazor standard, Bootstrap peut être configuré. Si c’est le cas, dans wwwroot tu auras un bootstrap dossier, et dans l’un de ses sous-dossiers il y aura quelques *.js fichiers.

ImportMap détectera automatiquement ces modules et restituera un élément de script de type importmap qui mappe ces scripts à leurs noms de fichiers avec empreintes digitales.

Vous pouvez le voir en action si vous inspectez le code source de votre application Blazor.

 <script type="importmap">{
  "imports": {
  	"./_framework/dotnet.js": "./_framework/dotnet.fg9wbywt7y.js",
    "./_framework/dotnet.native.js": "./_framework/dotnet.native.hjjnedf5fu.js",
    "./_framework/dotnet.runtime.js": "./_framework/dotnet.runtime.ju77aherdp.js",
    "./lib/bootstrap/dist/js/bootstrap.bundle.js": "./lib/bootstrap/dist/js/bootstrap.bundle.4094rpi4f9.js",
    "./lib/bootstrap/dist/js/bootstrap.bundle.min.js": "./lib/bootstrap/dist/js/bootstrap.bundle.min.hd3gran6i8.js",
    "./lib/bootstrap/dist/js/bootstrap.esm.js": "./lib/bootstrap/dist/js/bootstrap.esm.ltid2c489k.js",
    "./lib/bootstrap/dist/js/bootstrap.esm.min.js": "./lib/bootstrap/dist/js/bootstrap.esm.min.8vyfqsqgz1.js",
    "./lib/bootstrap/dist/js/bootstrap.min.js": "./lib/bootstrap/dist/js/bootstrap.min.4d85u1mtcx.js",
    "./lib/bootstrap/dist/js/bootstrap.js": "./lib/bootstrap/dist/js/bootstrap.u9q1upor1n.js",
    "./myscript.js": "./myscript.e66w4svn1c.js",
    
  },
  "integrity": {
    
  }
}</script>

Ici ImportMap a récupéré un certain nombre de scripts JS, y compris ceux de Bootstrap (trouvés dans wwwroot) et mon simple myscript.js exemple.

Si vous ne le connaissez pas, ImportMap est une fonctionnalité du navigateur permettant de contrôler la façon dont les modules JavaScript sont résolus. C’est nécessaire ici car nos applications tenteront d’importer des modules JavaScript en utilisant leur nom de fichier d’origine (par exemple, ./lib/bootstrap/dist/js/bootstrap.js).

La carte d’importation les redirigera vers la version empreinte (avec son nom de fichier unique, qui change lorsque vous publiez une nouvelle version).

Pour plus d’informations sur .NET 9 ImportMap composant (et comment le personnaliser), consultez la documentation officielle.

Supprimer des classes pour sérialiser l’état d’authentification

Si vous créez un nouveau projet à l’aide de .NET 8, qui prend en charge l’authentification ainsi que le rendu interactif, vous vous retrouvez avec du code passe-partout dans votre projet pour sérialiser l’état d’authentification.

Les fichiers concernés sont appelés PersistingRevalidatingAuthenticationStateProvider.cs et PersistentAuthenticationStateProvider.cs.

Il s’agit du mécanisme par lequel Blazor vérifie que l’état d’authentification actuel de l’utilisateur, tel que déterminé sur le serveur, est mis à la disposition de vos composants lors d’une exécution interactive via Blazor WASM.

Il crée essentiellement une chaîne représentant l’état d’authentification de l’utilisateur et l’intègre sous forme de commentaire dans le HTML servi au client. Lorsque votre application démarre à l’aide de Blazor WASM, elle lit cet état, ce qui vous permet d’utiliser les informations, par exemple pour afficher une interface utilisateur différente pour les utilisateurs anonymes (par rapport aux utilisateurs authentifiés).

Dans .NET 9, vous pouvez supprimer cette classe et activer le même comportement dans Programme.cs.

Dans votre projet de serveur, ajoutez AddAuthenticationStateSerialization() à l’appel existant à AddRazorComponents():

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

Et dans le projet client :

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


builder.Services.AddAuthenticationStateDeserialization();

Avec ces modifications, vous pouvez supprimer en toute sécurité les deux fichiers mentionnés ci-dessus et la logique d’authentification de votre composant devrait fonctionner exactement comme avant.

Profitez des nouvelles fonctionnalités de .NET 9 Blazor

Une fois que vous avez terminé les étapes ci-dessus, votre projet devrait être opérationnel avec .NET 9.

Voici quelques éléments que vous remarquerez peut-être/pourrez utiliser et qui étaient différents (ou n’existaient pas) dans .NET 8 et versions antérieures.

Meilleure reconnexion UX

Si vous utilisez Interactive Server et perdez la connexion au serveur, vous devriez voir la nouvelle interface utilisateur de reconnexion améliorée.

Migration vers Blazor Net9 - échec de la réadhésion

Cela tentera de se reconnecter en utilisant une stratégie d’attente exponentielle.

Blazor tentera de se reconnecter au circuit SignalR d’origine sur le serveur, ce qui signifie que les utilisateurs ne perdront aucun travail/progrès. Si cela échoue, l’application sera actualisée, en s’assurant que l’état dans le navigateur correspond à celui sur le serveur.

Tout compte fait, vous devriez constater que vos utilisateurs bénéficient d’une meilleure expérience lorsque la connexion au serveur est perdue et d’une chance de continuer là où ils s’étaient arrêtés (lorsque la connexion revient).

Si votre application est configurée pour utiliser le rendu interactif (WASM ou serveur) globalement pour l’ensemble de votre application, vous pouvez désormais l’abandonner pour utiliser le rendu statique côté serveur pour des composants spécifiques.

Vous devrez décorer le composant concerné avec un attribut :

@attribute [ExcludeFromInteractiveRouting]

Ajoutez ensuite un peu de logique à votre App.razor déposer:

@code {
    [CascadingParameter]
    private HttpContext HttpContext { get; set; } = default!;

    private IComponentRenderMode? PageRenderMode
        => HttpContext.AcceptsInteractiveRouting() ? InteractiveServer : null;
}

Avec ces changements, les composants décorés du ExcludeFromInteractiveRouting L’attribut sera rendu sur le serveur, en utilisant le rendu statique côté serveur.

Consultez cet article pour un exemple pratique, où nous ajouter une page de marketing statique à une application Blazor autrement interactive.

Connaissez vos modes de rendu

Enfin, l’un des changements les plus importants apportés à .NET 8 était la possibilité d’exécuter vos composants en utilisant différents modes de rendu.

En pratique, cela peut prêter à confusion si l’on tente de passer d’un mode à un autre. Cela aide si vous pouvez voir quel mode utilise un composant donné, et avec .NET 9, c’est désormais possible en utilisant le nouveau RendererInfo propriété.

Sur n’importe quel composant donné, vous pouvez accéder au RendererInfo propriété pour savoir où votre composant est exécuté et quel mode il utilise.

RendererInfo.Name vous dira où s’exécute votre composant (Static, Server, WebAssembly).

RendererInfo.IsInteractive indiquera s’il s’exécute actuellement de manière interactive (non statique).

Il y a aussi un AssignedRenderMode propriété. Celui-ci est utile si votre composant est pré-rendu, car il vous indiquera comment votre composant fonctionnera après le pré-rendu.

En résumé

.NET 9 représente une version plus légère pour Blazor, après les grands changements apportés à .NET 8.

La mise à niveau à partir de .NET 8 est généralement simple et nécessite quelques modifications minimes de vos fichiers de projet. À partir de là, vous pouvez activer de nouvelles fonctionnalités telles que le middleware amélioré de gestion des actifs statiques et supprimer certains codes passe-partout si vous choisissez d’utiliser le nouveau mécanisme de sérialisation de l’état d’authentification.

En dehors de cela, vous devriez commencer à voir d’autres changements mineurs tels que l’UX amélioré de reconnexion de Blazor Server.

Enfin, n’oubliez pas qu’il s’agit d’une version « Standard Term Support », elle sera donc prise en charge (et recevra des correctifs) pendant 18 mois après sa sortie (.NET 8, qui était une version LTS, est prise en charge pendant trois ans).

Le meilleur outil 2023 pour ta croissance Instagram !



Source link