Modes de rendu Blazor dans .NET 8

Dans cet article, nous découvrirons les nouveaux modes de rendu Blazor dans .NET 8, notamment ServerInteractivity, WebAssemblyInteractivity, AutoInteractivity et le rendu statique côté serveur (SSR).
Pour une introduction à Serveur Blazor et Blazor WebAssemblylisez les articles dans le Les bases du Blazor série.
Introduction
Auparavant, jusqu’à .NET 7, nous avions Blazor Server et Blazor WebAssembly comme modes de rendu dédiés et exclusifs. Avec .NET 8, nous disposons désormais de quatre modes de rendu différents.
De plus, nous pouvons désormais mélanger et faire correspondre différents modes de rendu au sein de la même application en définissant un mode de rendu par composant au lieu d’une application entière.
Lorsque vous utilisez le nouveau modèle de projet Blazor Web App, tout ce dont nous avons besoin est déjà configuré pour nous. Lorsque vous travaillez avec une application existante ou lorsque vous démarrez avec un modèle de projet différent, nous devons nous assurer que l’application est correctement configurée.
Tout d’abord, nous devons nous assurer d’ajouter la ligne suivante au Program.cs pour enregistrer les services requis pour les composants Razor :
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddRazorComponents()
var app = builder.Build();
app.Run();
Lorsque nous souhaitons activer l’interactivité de Blazor Server pour l’application, nous devons également appeler la méthode AddInteractiveServerComponents pour enregistrer les services requis.
builder.Services.AddRazorComponents()
.AddInteractiveServerComponents();
Par conséquent, nous devons également appeler la méthode AddInteractiveWebAssemblyComponents lorsque nous souhaitons configurer l’application pour prendre en charge les composants avec l’interaction WebAssembly.
builder.Services.AddRazorComponents()
.AddInteractiveWebAssemblyComponents();
Si nous souhaitons mélanger et assortir, nous pouvons également appeler les deux méthodes, permettant à l’application d’utiliser à la fois l’interactivité de Blazor Server ainsi que l’interactivité de WebAssembly au sein de la même application Blazor.
builder.Services.AddRazorComponents()
.AddInteractiveServerComponents()
.AddInteractiveWebAssemblyComponents();
Voyons maintenant si les nouveaux modes de rendu rendent Blazor plus complexe ou s’ils sont également utiles pour créer des applications Web modernes.
Application de modes de rendu à des composants individuels
Avec .NET 8, nous pouvons définir les modes de rendu pour des composants individuels de deux manières différentes.
Nous pouvons utiliser le
@rendermode
attribut lors de la définition d’une instance d’un composant. Par exemple, disons que nous avons unUser
composant. Lors de la définition d’une instance deUser
composant, nous ajoutons le@rendermode
et définissez la valeur sur l’interactivité du serveur :<User @rendermode="RenderMode.InteractiveServer" />
Cette approche est très flexible. Nous définissons le
User
composant indépendant du mode de rendu. Cela signifie que le composant peut être utilisé avec différents modes de rendu et que nous ne définissons pas de mode de rendu dans la définition du composant.Nous pouvons définir le mode de rendu dans l’implémentation du composant en utilisant le
@rendermode
attribut suivi du mode de rendu.@rendermode InteractiveServer <div>Username: @User.Username</div>
Dans cet exemple, le
User
Le composant est fixé sur un mode de rendu spécifique. Nous ne pouvons pas définir ou modifier le mode de rendu lors de la définition d’une instance du composant.Cette approche limite la flexibilité de l’application et ne doit être utilisée que si l’implémentation du composant limite l’utilisation de différents modes de rendu. Cela pourrait être le cas lorsque nous appelons des API backend dans les rappels d’événements, qui ne sont disponibles que dans l’interactivité de Blazor Server.
Prérendu des composants Blazor dans .NET 8
Le prérendu des composants permet au navigateur de restituer le composant pendant le chargement des données en arrière-plan. Dès que l’opération asynchrone est terminée, le composant est mis à jour avec les données chargées.
Cela aide l’application à se sentir plus réactive et pourrait également améliorer le référencement puisque l’application semble être plus rapide, ce qui augmente les signaux vers les moteurs de recherche.
Pendant la phase de prérendu, les gestionnaires d’événements ne sont pas actifs. Les composants ne réagissent pas aux actions de l’utilisateur.
Le prérendu est activé par défaut pour tous les composants interactifs.
Cela semble trop beau pour être vrai – et c’est peut-être le cas. Quel est le piège?
Le prérendu rend l’ensemble du processus de rendu beaucoup plus complexe. Bien que cela semble formidable d’avoir un composant rendu à l’écran le plus rapidement possible, cela comporte également des défis.
Comme expliqué ci-dessus, l’interactivité déclenchée alors que le prérendu n’est pas terminé est ignorée. Cela peut entraîner un comportement inattendu et une confusion parmi les utilisateurs.
D’après mon expérience de travail avec Blazor depuis quelques années, je recommande de désactiver le prérendu, sauf si vous en avez spécifiquement besoin dans un certain cas. À mon avis, le prérendu ne devrait pas être activé par défaut. Mais c’est une autre discussion à avoir.
Lorsque l’on souhaite désactiver le prérendu, on peut soit le faire lors de la définition du composant à l’aide d’une des lignes suivantes selon le mode d’interactivité souhaité :
@rendermode @(new InteractiveServerRenderMode(prerender: false))
@rendermode @(new InteractiveWebAssemblyRenderMode(prerender: false))
@rendermode @(new InteractiveAutoRenderMode(prerender: false))
Ou nous le définissons pour chaque instance d’un composant en utilisant le @rendermode
attribut:
<... @rendermode="new InteractiveServerRenderMode(prerender: false)" />
<... @rendermode="new InteractiveWebAssemblyRenderMode(prerender: false)" />
<... @rendermode="new InteractiveAutoRenderMode(prerender: false)" />
Si nous souhaitons désactiver le prérendu pour un composant spécifique, nous spécifions également son type d’interactivité.
Rendu statique côté serveur (Static SSR)
Si nous ne spécifions aucun mode d’interactivité sur un composant Blazor, le rendu statique côté serveur (static SSR) est utilisé.
Cela signifie qu’il n’y a pas d’interactivité car la page est rendue sur le serveur et renvoyée au client sans aucune interactivité (code de rappel, etc.). Par conséquent, tous les rappels de bouton sont ignorés et ne seront pas déclenchés lorsque l’utilisateur appuie sur le bouton.
Le SSR statique est logique pour les sites Web sans aucune interactivité. Par exemple, pour créer des sites Web ou des blogs d’entreprise qui affichent principalement des données, le SSR statique est un excellent choix. Bien sûr, nous pouvons toujours avoir certains composants interactifs, mais nous n’en avons pas besoin pour la plupart des composants.
Avant .NET 8, nous avions toujours une connexion SignalR (à cause de Blazor Server) ou un bundle important pour WebAssembly. Avec le SSR statique, nous pouvons restituer le site Web sur le serveur et envoyer du HTML, CSS (et JavaScript) au serveur. C’est rapide, simple et idéal pour le référencement.
Avis: Lorsque nous souhaitons avoir de l’interactivité sur les composants Blazor, nous devons définir le mode d’interactivité sur Server, WebAssembly ou Auto. Sinon, il n’y a pas d’interactivité et nos composants utilisent du SSR statique.
Rendu interactif côté serveur (Blazor Server)
Ce qui était auparavant connu sous le nom de Blazor Server s’appelle désormais InteractiveServer
le rendu.
@rendermode InteractiveServer
Si nous définissons le mode de rendu d’un composant sur InteractiveServer
le code d’interactivité est exécuté sur le serveur, similaire à une application Blazor Server exécutée sur .NET 7 ou version antérieure.
Rendu côté client à l’aide de Blazor WebAssembly
Ce qui était auparavant connu sous le nom de Blazor WebAssembly s’appelle désormais InteractiveWebAssembly
.
@rendermode InteractiveWebAssembly
Si nous définissons le mode de rendu d’un composant sur InteractiveWebAssembly
, le code d’interactivité est exécuté sur le client à l’aide de WebAssembly. Le composant se comporte de la même manière qu’une application Blazor WebAssembly exécutée sur .NET 7 ou une version antérieure.
Le mode de rendu automatique interactif
Tandis que le InteractiveServer
et InteractiveWebAssembly
les modes de rendu existent depuis quelques années, le InteractiveAuto
le mode de rendu a été introduit avec .NET 8.
Le mode de rendu automatique décide comment restituer le composant au moment de l’exécution. Tout d’abord, le composant est rendu en utilisant InteractiveServer
. En arrière-plan, le runtime .NET et l’app bundle sont téléchargés et mis en cache côté client.
La prochaine fois que le composant sera rendu, il utilisera l’exécutable client et restituera le composant en utilisant InteractiveWebAssembly
.
Important: Le mode de rendu automatique ne modifie pas le type d’interactivité au moment de l’exécution pour un composant déjà rendu. En d’autres termes, le composant ne change pas de
InteractivityServer
àInteractivtiyWebAssembly
. Il utilise toujours l’un de ces types d’interactivité et s’y tient jusqu’à ce que le composant soit utilisé à un autre endroit de l’application ou lorsque l’application est rechargée.
J’ai personnellement eu une expérience mitigée avec le mode de rendu automatique. Bien que cela semble être un bon plan de bénéficier à la fois de temps de chargement rapides et d’une interactivité sans latence dès que le bundle WebAssembly est disponible, j’ai constaté quelques problèmes de comportement imprévisible. En outre, cela introduit plus de complexité dans l’application.
Comme toujours, c’est un excellent outil pour certaines applications, mais pas la bonne méthode pour toutes.
Utiliser le même mode de rendu pour l’ensemble de l’application
Parfois, nous, les développeurs, voulons rendre notre vie aussi simple que possible. Et c’est une bonne chose.
Si nous avons un scénario dans lequel nous souhaitons utiliser le même mode de rendu pour tous les composants de l’ensemble de l’application Web Blazor, il est logique de définir globalement le mode de rendu.
Malheureusement, cela signifie actuellement que nous devons définir le mode de rendu à deux endroits. Au moins les deux sont dans le même fichier, le composant App.
Le Routes
et HeadOutlet
les composants sont l’endroit où nous devons appliquer le @rendermode
attribut si nous voulons définir le mode de rendu globalement.
Prenons l’exemple suivant :
<!DOCTYPE html>
<html lang="en">
<head>
<base href="/" />
<HeadOutlet @rendermode="new InteractiveServerRenderMode(prerender: false)" />
</head>
<body>
<Routes @rendermode="new InteractiveServerRenderMode(prerender: false)" />
<script src="_framework/blazor.web.js"></script>
</body>
</html>
Comme vous pouvez le constater, nous avons la même définition pour les deux HeadOutlet
et le Routes
Composants.
J’aurais aimé qu’il y ait un endroit central où nous n’aurions à le placer qu’une seule fois, mais c’est mieux que rien.
Lorsque nous définissons le mode de rendu globalement, nous n’avons pas à nous en soucier dans l’ensemble de l’application. Nous n’avons pas besoin de définir le mode de rendu sur des instances de composants individuelles ou lors de l’implémentation de ces composants.
Conclusion
Deux des quatre modes de rendu disponibles dans .NET 8 sont connus des développeurs Blazor à partir des versions antérieures de .NET.
Deux modes SSR automatique et statique ont été introduits avec .NET 8 et ont ouvert de nouvelles opportunités pour créer des applications Blazor pour des scénarios supplémentaires.
Cependant, avec les nouveaux modes de rendu, un autre niveau de complexité est introduit dans vos applications Web Blazor. Par conséquent, je vous recommande fortement de vous familiariser avec les quatre modes de rendu et de choisir celui qui convient le mieux à votre scénario.
Ce n’est pas une honte de continuer ServerInteractivity
ou WebAssemblyInteractivity
pour la simplicité. Au contraire, je le recommande fortement pour la plupart des scénarios.
Si vous souhaitez en savoir plus sur le développement de Blazor, vous pouvez regarder mon cours intensif Blazor gratuit sur YouTube. Et restez à l’écoute du blog Telerik pour en savoir plus Les bases du Blazor.
Source link