Une autre année, une autre version .NET à attendre avec impatience.
Cela fait quelques mois avant le lancement .NET 10, mais les versions de prévisualisation atterrissent déjà. Voici quelques points forts de ce que nous avons vu jusqu’à présent, les problèmes résolus et les indices sur ce à quoi nous pouvons nous attendre alors que nous nous rapprochons de la version RTM en novembre.
Le script de blazor a servi d’atout statique
L’un des changements notables de .NET 9 a été révisé au middleware pour la gestion des actifs statiques dans vos applications Blazor. Ce changement signifiait que vos actifs statiques (fichiers CSS, JS) sont automatiquement compressés et empreinés par les digitales, ils jouent donc bien avec la mise en cache et minimisent combien vos utilisateurs ont à télécharger avant que votre site ne monte dans la vie.
Mais le script Blazor lui-même a été servi en dehors de ce middleware.
Dans .NET 10, le script Blazor bénéficie désormais de la même précompression automatique et de l’empreinte digitale pour réduire la taille de téléchargement et améliorer la mise en cache du fichier. Avec ce changement, blazor.web.js Chute de 183 Ko à 43 Ko (réduction de taille 76%).
Personnalisation plus facile des lignes dans QuickGrid
Si vous recherchez un moyen rapide et facile d’afficher les données tabulaires, Microsoft QuickGrid est une option solide. Mais c’était difficile dans les versions précédentes pour modifier le style d’une ligne en fonction de l’élément rendu.
Le nouveau RowClass Le paramètre aborde ceci. Vous pouvez maintenant changer le style d’une ligne conditionnellement, comme ceci:
<QuickGrid ... RowClass="GetRowClass">
...
</QuickGrid>
@code {
private record OrderLine(int Id, string Item, int Quantity, bool Shipped);
private string GetRowClass(OrderLine line) =>
line.Shipped ? "highlight" : null;
}
Plus de sauts avec Navigateto
Dans les versions précédentes de .net, lorsque vous avez utilisé NavigateTo Pour accéder à la même page dans une application Blazor avec un routeur interactif (donc en cours d’exécution avec l’un des modes de rendu interactifs de Blazor), le navigateur fait défiler en haut de la page. C’était une douleur si tu as utilisé NavigateTo Pour modifier la chaîne de requête, ou fragment pour la page actuelle.
Maintenant, la position de défilement sera conservée. (Cela fonctionne également pour la navigation vers l’avant et vers l’arrière vers la même page.)
Navlinks devient plus intelligent
NavLink est un composant pratique de Blazor qui applique automatiquement une classe CSS à un lien lorsque le lien et l’URL actuelle de la page correspondent. Ceci est utile lorsque vous souhaitez afficher, sur un menu NAV, quelle page est actuellement sélectionnée.
Avec .net 10, NavLink Ignorera désormais la chaîne de requête et le fragment lorsque vous utilisez le NavLinkMatch.All valeur pour le Match paramètre. En effet, cela signifie que le lien restera actif ( active Classe) Si l’URL correspond, quelle que soit la chaîne de requête et le fragment.
Vous pouvez revenir au comportement d’origine en utilisant le nom de Snapply Microsoft.AspNetCore.Components.Routing.NavLink.DisableMatchAllIgnoresLeftUriPart Commutateur AppContext.
Vous pouvez également créer votre propre version de NavLink et remplacer la logique pour déterminer si une URL correspond ou non.
public class FancyNavLink : NavLink
{
protected override bool ShouldMatch(string currentUriAbsolute)
{
bool shouldMatch = false;
var href = this.AdditionalAttributes?["href"];
return shouldMatch;
}
}
UI de reconnexion facilement personnalisée
Le modèle d’application Web Blazor comprend désormais le balisage, CSS et JS pour le composant de l’interface utilisateur de reconnexion standard.
Il s’agit de l’interface utilisateur qui sera affichée lorsque votre client perd la connexion WebSocket au serveur.
Si vous choisissez de ne pas utiliser ce composant, une interface utilisateur de reconnexion par défaut sera utilisée comme repli.
Il y a aussi maintenant un components-reconnect-state-changed Événement envoyé lorsque l’état de reconnexion change. Et il y a un nouvel état de reconnexion de retryingque vous pouvez gérer dans votre interface utilisateur de reconnexion.
Modèle déclaratif pour l’état persistant
Par défaut, vos composants de Blazor sont prépendus – ce qui signifie qu’ils sont rendus une fois sur le serveur, auquel cas le HTML rendu est renvoyé et affiché dans le navigateur.
Ensuite, le composant est à nouveau rendu, soit sur le serveur ou le client (selon que vous utilisez Blazor Server ou WebAssembly).
Le résultat est que vous pouvez obtenir un effet visible où vous voyez des données apparaître (après la précharge), puis «flash» lorsque les données sont récupérées et rendues, à nouveau dans l’un des modes interactifs de Blazor.
Vous pouvez éviter cette deuxième charge par l’état persistant à partir du préender, donc votre composant utilise cet état persistant lorsqu’il se rend en mode interactif. Mais aujourd’hui, il faut pas mal de code de passe-partout pour y arriver, créant un PersistingComponentStateSubscriptionen utilisant ApplicationState chercher un état persistant et éliminer tout correctement.
Dans .NET 10, vous pouvez le faire avec un seul attribut.
@code {
[SupplyParameterFromPersistentComponentState]
public List<User>? Users { get; set; }
protected override async Task OnInitializedAsync()
{
Users ??= await UserService.GetUsersAsync();
}
}
Avec cela, lorsque le composant prétend, la liste d’utilisateurs sera stockée à l’état persistant. Il sera sérialisé et envoyé «sur le fil» à l’application Blazor en cours d’exécution en serveur interactif ou en mode WebAssembly interactif.
Les applications Blazor Wasm peuvent référencer les versions empreintes digitales des actifs Web statiques
Les applications WasM Blazor Standalone Blazor (celles non hébergées via ASP.NET Core) peuvent référence à Framework des actifs Web statiques.
Il nécessite ce paramètre dans votre fichier CSPROJ:
<Project Sdk="Microsoft.NET.Sdk.BlazorWebAssembly">
<PropertyGroup>
<TargetFramework>net10.0</TargetFramework>
+ <WriteImportMapToHtml>true</WriteImportMapToHtml>
</PropertyGroup>
</Project>
Alors vous devrez inclure un vide <script type="importmap"></script> élément dans votre fichier index.html:
<head>
....
+ <script type="importmap"></script>
</head>
Avec cela en place, vous pouvez ensuite référencer la version empreinte digitale du blazor.webassembly.js script comme ceci:
<body>
...
<script src="_framework/blazor.webassembly#[.{fingerprint}].js"></script>
</body>
En effet, cela vous permettra d’obtenir toujours la dernière version de blazor.webassembly.js Avec un nom de fichier unique généré sur la base du contenu du fichier, ce qui signifie que vous ne devriez jamais vous retrouver avec une version périmée du cache lorsque vous déployez des applications autonomes Blazor améliorées.
En ce qui concerne la façon dont cela fonctionne réellement, si vous regardez le code source de votre application lorsqu’il s’exécute dans le navigateur, vous verrez quelque chose comme ceci:
<script type="importmap">{
"imports": {
"./_framework/blazor.webassembly.js": "./_framework/blazor.webassembly.7ksmg6ui0q.js",
...
},
"scopes": {},
"integrity": {
"./_framework/blazor.webassembly.7ksmg6ui0q.js": "sha256-6X2pDdgzF4O/SgWURawQ2TGvk7fRgPqWOrHkEpM1vJk=",
"./_framework/blazor.webassembly.js": "sha256-6X2pDdgzF4O/SgWURawQ2TGvk7fRgPqWOrHkEpM1vJk=",
...
}
}</script>
Il y aura beaucoup plus d’entrées, mais j’en ai omis la plupart pour la brièveté!
Ici, vous pouvez voir comment Blazor a généré une carte d’importation. Cela signifie n’importe quel js dans votre application qui importe ./_framework/blazor.webassembly.js sera redirigé vers le nom de fichier à empreintes digitales correctement.
Vous verrez également que cette ligne:
<script src="_framework/blazor.webassembly#[.{fingerprint}].js"></script>
A été remplacé par quelque chose comme ceci:
<script src="_framework/blazor.webassembly.7ksmg6ui0q.js"></script>
Les applications autonomes de Blazor Wasm peuvent désormais définir l’environnement au moment de la construction
Si vous souhaitez contrôler l’environnement de votre application Blazor WebAssembly, vous pouvez désormais la définir à l’heure de construction en utilisant cette propriété dans votre .csproj déposer:
<WasmApplicationEnvironmentName>Staging</WasmApplicationEnvironmentName>
Auparavant, .NET utiliserait l’en-tête Blazor-Environment pour définir l’environnement.
Cette nouvelle approche signifie que vous pouvez le définir dans les environnements CI / CD et / ou lors de la publication par d’autres moyens afin que vous utilisez la configuration correcte pour votre environnement choisi.
En résumé
Cet article aborde les principales modifications qui ont émergé dans les trois premières versions de prévisualisation pour .NET 10.
À venir (de la feuille de route) sont:
- Métriques pour le blazor
- Prise en charge de l’état des composants persistants à travers les navigations de page améliorées (lors de l’utilisation de Blazor SSR)
- Option Microsoft Identity Platform Auth pour le modèle d’application Web Blazor
De plus, beaucoup de corrections de bogues.
Source link