Quoi de neuf pour Blazor dans .NET 7 ?

.NET 7 devrait sortir plus tard cette année, mais qu’apportera-t-il aux développeurs Blazor ?

Les premières versions d’aperçu d’ASP.NET 7 ont été publiées et vous avez peut-être remarqué qu’elles n’ont pas inclus beaucoup de modifications Blazor (le cas échéant). En lisant entre les lignes, cela est probablement dû à l’accent mis par l’équipe sur .NET MAUI.

Dan Roth a indiqué (lors d’une stand-up récent de la communauté ASP.NET) que .NET MAUI sera la première grande version liée à Blazor en 2022.

.NET MAUI est sur le point d’amener Blazor au développement d’applications nativespermettant de créer des applications pour Windows, Mac, iOS et Android en utilisant vos connaissances et compétences Blazor.

Une fois que .NET MAUI est officiellement publié, nous pouvons nous attendre à voir des améliorations plus importantes de Blazor dans les versions d’aperçu .NET suivantes. Mais à quoi peut-on s’attendre exactement ?

Voici une liste, basée sur les commentaires publics et les problèmes GitHub publiés, des nouvelles fonctionnalités et améliorations possibles qui pourraient atterrir avec .NET 7.

Améliorations du rechargement à chaud

.NET 6 introduit Rechargement à chaud—la possibilité pour votre navigateur de refléter automatiquement les modifications que vous apportez au cours du développement (sans effectuer une reconstruction complète de l’application).

Alors que .NET 6 a fait de grands progrès avec Hot Reload, l’expérience peut encore être un peu hasardeuse. Il existe des plans avec .NET 7 pour combler certaines lacunes dans la prise en charge existante du rechargement à chaud, notamment :

• Gérer plus de modifications (celles qui nécessitent un redémarrage complet du serveur avec .NET 6)
• Permettre d’utiliser le rechargement à chaud lors du débogage des applications Blazor WASM
• Mise à niveau de la prise en charge du rechargement à chaud de Blazor WASM avec la prise en charge d’autres parties de .NET (telles que les pages ASP.NET Razor, MVC)

Améliorations AOT (Ahead Of Time Compilation)

.NET 6 a introduit la possibilité de compiler des applications Blazor sur WASM, offrant des performances plus rapides au prix d’une taille de bundle d’applications accrue (les applications compilées par AOT peuvent être jusqu’à 2 fois plus grandes).

Sans AOT, vos applications Blazor WASM s’exécutent à l’aide d’un interpréteur .NET IL (langage intermédiaire). Alors que l’interpréteur est implémenté dans WebAssembly, votre application ne l’est pas.

Inversement, avec AOT, votre application est compilée directement dans WebAssembly.

Microsoft envisage d’introduire un mode mixte AOT pour .NET 7, qui vous permettrait d’utiliser AOT de manière sélective, pour des parties spécifiques de votre application. Avec cela, vous pouvez utiliser AOT pour les « chemins chauds » de votre application (où les performances sont importantes) sans augmenter massivement la taille de votre application globale.

En plus du mode mixte, l’équipe explore des moyens d’améliorer les performances AOT :

• Réglage du processus AOT (en particulier pour traiter les zones où ils doivent actuellement se connecter à l’interpréteur, ce qui entraîne une réduction des performances)
• Explorer d’autres moyens de réduire le code inutile afin de réduire la taille globale de l’application

Multithreading

Blazor WASM s’exécute actuellement sur un seul thread dans le navigateur (en particulier, il exécute tout sur le « UI Thread »).

Les navigateurs ont désormais introduit la prise en charge du multithreading. Ce support existait auparavant mais a été désactivé pendant plusieurs années en raison de problèmes de sécurité. Maintenant que la prise en charge du multithreading est de retour, Microsoft espère l’utiliser pour Blazor dans .NET 7.

Les principaux cas d’utilisation sont susceptibles d’être des tâches de longue durée et/ou des tâches gourmandes en ressources de calcul. En déplaçant ce travail sur des threads séparés, vous pourrez garder votre interface utilisateur Blazor rapide et réactive (pendant que le travail se poursuit en arrière-plan).

Assemblage Web .NET sans interface utilisateur Blazor

Si vous souhaitez créer une application Web avec une interface utilisateur qui s’exécute sur WebAssembly, alors Blazor WASM est un bon choix.

Mais que se passe-t-il si vous souhaitez utiliser une bibliothèque .NET dans le navigateur sans implémenter une interface utilisateur Blazor, par exemple à partir d’une application JavaScript ?

Les modifications proposées vous permettraient de prendre une bibliothèque .NET existante et de la réutiliser dans le navigateur même si vous n’utilisiez pas Blazor, vous ouvrant ainsi la porte à la réutilisation de toutes sortes de bibliothèques .NET pratiques.

Améliorations de la gestion des connexions au serveur Blazor

Avec .NET 6 (et versions antérieures), lorsque vous redéployez ou redémarrez votre application Blazor Server, vos utilisateurs verront probablement un message leur demandant de redémarrer l’application.

Il est prévu que .NET 7 fournisse plus de contrôle sur les durées de vie du circuit SignalR sous-jacent, ainsi que pour prendre en charge la pause et la reprise des applications Blazor Server.

Cela inclurait un mécanisme pour mettre en veille prolongée l’état des composants, puis, dans le cas où le navigateur perdrait la connexion au serveur, restaurer cet état lorsque l’application reviendrait.

Si MS supprime ces modifications, cela pourrait répondre à l’une des principales préoccupations des développeurs à propos de Blazor Server : comment gérer les connexions perdues au serveur.

Prérendu avec authentification

Le prérendu permet aux visiteurs de votre site d’interagir avec votre site Blazor avant la fin du téléchargement initial.

Cela fonctionne en effectuant un rendu initial sur le serveur. HTML est ensuite servi au navigateur, ce qui signifie que vos utilisateurs ont quelque chose avec quoi travailler pendant que le navigateur télécharge le runtime Blazor WASM .NET (et votre application) en arrière-plan.

Une lacune importante dans le prérendu Blazor concerne les applications qui nécessitent une authentification.

À ce jour, le prérendu pour les itinéraires nécessitant une authentification n’a pas vraiment été possible, ce qui signifie que vous ne pouvez pas prérendre les pages qui affichent des données spécifiques à l’utilisateur.

On ne sait pas encore exactement comment cela fonctionnera, mais toute solution permettra probablement au serveur d’accéder aux détails de l’utilisateur pendant la phase de pré-rendu.

@bind:after et @bind:get/set

Parfois, vous souhaiterez peut-être exécuter une logique supplémentaire après la modification d’une partie de votre interface utilisateur.

Steve Sanderson en donne un exemple pratique dans le Problème GitHub pour ce changement:

<input @bind="searchText" @bind:after="PerformSearch" />

@code {
    string searchText;

    async Task PerformSearch()
    {
        // ... do something asynchronously with 'searchText' ...
    }
}

La proposition @bind:after vue ici faciliterait beaucoup l’exécution du code en réponse à la searchText valeur en cours de modification (dans ce cas, par l’utilisateur saisissant une nouvelle valeur dans input).

Ceci est particulièrement utile car le processus de liaison habituel de Blazor, les vérifications et les sécurités, se seront produits, vous garantissant l’accès à des informations à jour à partir de ce searchText champ lors de l’exécution de la logique dans PerformSearch.

Blazor pourrait également invoquer votre code (dans ce cas, votre logique dans PerformSearch) avant toute tentative de re-rendre votre composant, ce qui signifie que vous pouvez apporter des modifications en toute sécurité dans PerformSearch qui déclenchent un re-rendu supplémentaire sans rencontrer de problèmes liés à l’exécution d’un trop grand nombre de re-rendus enchaînés.

Pour comprendre pourquoi c’est un gros problème, il est utile de réfléchir à la façon dont vous géreriez cela aujourd’hui.

Avec .NET 6, il n’existe aucun moyen intégré évident de réagir aux modifications de liaison. Si quoi que ce soit, il serait plus facile de mettre un bouton à côté de la recherche afin que vous ayez quelque chose de concret auquel vous pourriez câbler un gestionnaire d’événements (pour effectuer la recherche proprement dite).

Ainsi que @bind:afteret pour un contrôle plus précis du processus de liaison, il est également proposé d’introduire @bind:get et @bind:set attributs directifs.

Ceux-ci permettraient de mettre en œuvre votre propre Value et ValueChanged propriétés comme ceci:

<input @bind:get="@SearchText" @bind:set="@SearchTextChanged" />

@code {
    [Parameter] public TValue SearchText { get; set; }
    [Parameter] public EventCallback<TValue> SearchTextChanged { get; set; }
}

Cela exposerait la EventCallback à appeler lorsque la valeur dans la recherche input changements.

Modèles vides

En plus du modèle de projet Blazor standard que nous connaissons tous et que nous aimons tous ? Microsoft fournira également un modèle plus simple, avec moins de code et d’interface utilisateur préexistants.

Des modifications mineures sont également proposées aux modèles existants, notamment la simplification de la structure et la refonte du thème.

Micro-interfaces ?

Enfin, un certain nombre de modifications proposées apporteraient plus de flexibilité dans la manière dont vous pouvez intégrer Blazor dans vos applications Web.

Il est notamment prévu de :

• Mélangez Blazor Server et WASM (pour pouvoir utiliser les deux dans la même application)
• Exécutez plusieurs applications Blazor sur la même page (actuellement, vous ne pouvez en avoir qu’une)
• Rendez les composants Blazor à partir de vos applications JavaScript (et incluez-les dans vos applications Angular et React)

Vous avez peut-être entendu le terme « architecture micro-frontend ». C’est une approche dans laquelle les applications frontales traditionnellement plus grandes (monolithiques) sont divisées en applications plus petites. Tout comme les microservices pour le développement backend, cela ouvre la porte à l’utilisation du « meilleur outil pour le travail » lors du choix des frameworks et des outils à utiliser pour créer des parties de votre interface utilisateur.

Ces modifications proposées pour Blazor sont un pas dans cette direction, facilitant l’adoption de Blazor pour certaines, mais pas nécessairement toutes, de votre interface utilisateur Web.

De plus, la prise en charge des éléments personnalisés permettra d’enregistrer vos composants Blazor afin que vous puissiez les utiliser à partir de vos applications Angular et React.

Autres améliorations générales

Enfin, il existe de nombreux changements, plus petits, inclus dans l’actuel feuille de route pour .NET 7.

Quelques-uns qui sautent aux yeux :

• UN LocationChanging événement pour NavigationManager (implémenter la logique qui se produit avant que la navigation ait lieu)
• DateOnly et TimeOnly prise en charge du routage Blazor
• Meilleure prise en charge de MSAL pour des scénarios supplémentaires (options pour transmettre des arguments supplémentaires à la bibliothèque MSAL sous-jacente, utilisée lors de l’authentification dans le navigateur)

En résumé

Il convient de noter que les plans changent et que les éléments mentionnés ici pourraient ne pas faire la différence pour .NET 7 (et des éléments non actuellement inclus dans la feuille de route pourraient encore être ajoutés), mais ceux-ci semblent être des paris solides pour la sortie de .NET 7 en novembre 2022 .

En examinant la liste, il est intéressant de considérer la maturité de Blazor à ce stade.

Après avoir fait de grands progrès ces dernières années (du prototype au produit officiellement pris en charge), les modifications proposées pour Blazor dans .NET 7 sont généralement des améliorations incrémentielles, des mises à jour des outils ou une extension des scénarios dans lesquels Blazor peut être utilisé.

Il semble que les plus grands changements de « Blazor » arrivent plus tôt en 2022 lors du lancement de .NET MAUI, amenant Blazor dans le monde du développement d’applications natives.