Interactivité Blazor

Blazor vous permet de livrer un portail dans l’un des trois modes d’interactivité — Serveur, WebAssembly ou Auto. Le mode choisit comment les composants interactifs s’exécutent (via une connexion SignalR sur le serveur, tel que compilé .NET dans le navigateur, ou les deux) et décide ce qui est généré dans la mise en page de votre projet. Power Portals Pro fonctionne correctement sous les trois ; Les différences résident dans la forme de déploiement et le câblage du projet, pas dans les fonctionnalités du cadre.

Les Trois Modes

Serveur

Les composants interactifs s’exécutent sur le serveur. Chaque utilisateur connecté détient une connexion SignalR ouverte vers l’hôte, et chaque événement UI fait des allers-retours vers le serveur.

• Le plus petit téléchargement client. Le navigateur reçoit du HTML simple et un petit chargeur SignalR — aucun runtime .NET n’est livré au client.
• Capacités complètes du serveur. Les composants injectent directement tout service côté serveur (client Dataverse, configuration, système de fichiers) sans passer par HTTP.
• Le déploiement le plus simple. Un ASP.NET hôte Core, pas de bundle WebAssembly séparé à publier.

Compromis :

• Hôte ambitieux. Le circuit de chaque utilisateur est épinglé sur une instance serveur unique ; L’échelle horizontale nécessite des sessions épinglées, et un redémarrage de l’hôte est interrompu à chaque session active.
• La latence de l’interface utilisateur suit la latence réseau. Chaque clic, frappe et défilement fait des allers-retours vers le serveur, donc les utilisateurs sur des liens à haute latence ressentent l’application comme lente.

WebAssembly

Les composants interactifs s’exécutent dans le navigateur sous forme de code compilé .NET. Le rôle du serveur se réduit à servir les fichiers statiques et les points d’accès HTTP API du framework sous /api/auth/* et /api/*.

• Serveur sans état. L’hôte évolue horizontalement sans sessions épinglantes, les redémarrages ne causent aucune perturbation visible, et le coût mémoire par utilisateur sur le serveur est proche de nulle.
• Interface rapide. La plupart des interactions restent à l’intérieur du navigateur — pas de SignalR aller-retour par clic — donc l’application semble instantanée une fois le pack chargé.
• Capable de se connecter. Un portail chargé continue de s’afficher et de valider contre des données mises en cache même lorsque le réseau tombe, puis se synchronise à nouveau avec l’API à son retour.

Compromis :

• Téléchargement initial. Le runtime .NET, les assemblages du framework et le code de votre portail sont livrés au navigateur dès le premier chargement (compressé, souvent quelques Mo). Les visites suivantes se chargent depuis le cache du navigateur.
• Surface API requise. Tout ce dont l’interface utilisateur a besoin du serveur doit être exposé comme un point de terminaison HTTP. Power Portals Pro fournit les données et les points d’authentification dès la première utilisation ; la logique serveur personnalisée nécessite ses propres contrôleurs ou des terminaux à API minimale.
• Performances côté navigateur. Le travail à forte intensité CPU (grandes grilles, calculs graphiques complexes) s’exécute à la vitesse WebAssembly, qui est rapide mais plus lente que le .NET natif côté serveur.

Auto

La première peinture provient du serveur (pour que l’utilisateur voie immédiatement le contenu) et l’exécution passe de manière transparente vers WebAssembly une fois le paquet client terminé. Auto = Serveur en premier, WebAssembly ensuite, sur les mêmes itinéraires.

• Meilleure charge perçue + meilleure expérience utilisateur en régime permanent. Les utilisateurs bénéficient d’une première peinture instantanée sans attendre le bundle WASM, puis profitent des interactions rapides de WebAssembly une fois que l’exécution est mise en cache dans leur navigateur.
• Déploiement unique. Un hôte, une étape de publication — comme dans WebAssembly, avec l’exécution du serveur en main pendant le prére-rendu.

Compromis :

• La mise en page de projet la plus complexe. Les deux temps d’exécution doivent être câblés ; Les composants doivent fonctionner correctement sous l’un ou l’autre des moteurs de rendu (aucun service serveur uniquement injecté dans les composants partagés).
• Brève fenêtre rendue par le serveur. Lors de la première visite, la page affiche côté serveur jusqu’à la fin du swap WASM — le modèle de Power Portals Pro masque cette transition avec une superposition de chargement afin que les utilisateurs ne voient pas l’état intermédiaire.

Conseil

Ce site de documentation fonctionne en mode Auto. Ouvrez l’onglet réseau des outils de développement du navigateur lors du premier chargement et vous verrez le HTML rendu par le serveur arriver en premier, puis le flux du bundle WASM en une ou deux secondes — après quoi les navigations cessent de toucher le serveur pour le HTML.

Lequel choisir

Règles générales lorsqu’il n’y a pas de contrainte spécifique imposant un choix :

• Choisissez Server si le portail compte peu d’utilisateurs simultanés, fonctionne dans un réseau d’entreprise avec des connexions stables, ou si votre équipe est nouvelle sur Blazor et souhaite le modèle mental le plus simple.
• Choisissez WebAssembly si le portail est orienté client avec une forte concurrence, si votre facture d’hébergement évolue avec les sessions actives, ou si vous avez besoin d’un comportement hors ligne. Acceptez le coût initial de téléchargement comme un passage unique par visiteur.
• Choisissez Auto si vous voulez le WebAssembly en état stable sans payer la latence de la première peinture pour le téléchargement du bundle. La plupart des portails de production se retrouvent ici.

Fiche de triche

Ce qui change entre les trois modes, fichier par fichier. Utilisez cette référence pour comparer un projet généré à l’un des modèles, ou pour rechercher une divergence après un changement manuel.

Disposition du projet

Les trois modes génèrent un projet hôte serveur ET un projet frère. .Client Ce qui diffère, c’est le .ClientSDK de 's et s’il est réellement compilé en bundle WebAssembly.

• Server — .Client utilise Microsoft.NET.Sdk.Razor; c’est une bibliothèque de classes qui contient des composants partagés mais n’est pas publiée sous le nom WASM.
• WebAssembly — .Client utilisé Microsoft.NET.Sdk.BlazorWebAssembly avec son propre Program.cs, compilé en un pack téléchargeable.
• Auto — identique à WebAssembly : Microsoft.NET.Sdk.BlazorWebAssembly avec son propre Program.csfichier .

.csproj Différences

Le .Client SDK du projet change, et les paquets frameworks spécifiques à WebAssembly n’apparaissent que lorsque l’hôte exécute effectivement WASM :

Références supplémentaires de paquet lorsque WebAssembly ou Auto sont actifs :

Server Program.cs — Enregistrement des services

AddRazorComponents() sélectionne les paires de composants de mode de rendu appropriées en fonction des méthodes de construction chaînées :

Server Program.cs — Endpoint Mapping

MapRazorComponents<App>() enchaîne les terminaux correspondants en mode de rendu :

App.razor — Politique de rendu par itinéraire

Le PageRenderMode getter in App.razor décide quel moteur de rendu chaque route utilise. Les hôtes serveurs renvoient le serveur partout ; Les hôtes WebAssembly et Auto doivent épingler explicitement les /Account/* routes afin que le WASM uniquement IAuthService résout :

Pourquoi le compte /Account/* est épinglé

La première peinture d’Auto s’exécute sous le moteur de rendu du serveur, mais les pages IAuthService de compte ne sont enregistrées que dans le graphe DI du client WASM. Sans l’épingle explicite à InteractiveWebAssemblyRenderMode(prerender: false), un hôte Auto ne résout [Inject] IAuthService pas lors du prérendu de la session froide. prerender: false Ignore complètement l’étape de pré-rendu côté serveur, donc la page ne s’affiche qu’une seule fois, sur l’exécution WASM.

. Client/Program.cs — Uniquement en cas d’interactivité

Les hôtes serveur uniquement n’ont pas du tout de bibliothèque .Client/Program.cs de classe Razor .Client ). Les hôtes WebAssembly et Auto incluent ce fichier, qui configure l’exécution WASM, enregistre le HttpClient transfert des identifiants des cookies, enregistre les services clients WASM de Power Portals Pro, et pré-recherche la localisation transversale au démarrage :

Pages d’identité / de comptes

Power Portals Pro propose deux ensembles parallèles de pages de comptes — une pour chaque contexte de rendu. Le jeu dans votre projet dépend du mode de l’hôte :

• Serveur — pages Razor rendues par le serveur sous Components/Account/Pages/ utilisation UserManager directe. Les terminaux de formulaire sont enregistrés via app.MapAdditionalIdentityEndpoints().
• WebAssembly / Auto — pages interactives utilisant .Client/Pages/Account/ l’enveloppe du IAuthService framework. Les terminaux JSON s’enregistraient via app.MapAuthEndpoints<PortalUser>() la gestion de la connexion, l’enregistrement, la gestion/*, et la complétion de connexion externe en tant qu’appels application/json .

Prochaines étapes

Si vous avez déjà un projet sur un mode et souhaitez convertir vers un autre, consultez la page Switch Blazor Interactivity pour les modifications fichier par fichier.