Interactivité Switch Blazor

Passer d’un mode d’interactivité à un autre projet existant de Power Portals Pro consiste en une série de modifications sur Program.cs, App.razor, le .Client projet, et (en ajoutant l’interactivité) les pages de compte. Le cadre lui-même n’a pas besoin de modifications — seul le câblage de l’hôte en a besoin. Les étapes ci-dessous couvrent les transitions courantes.

Conseil

Si vos personnalisations se trouvent sur un petit nombre de pages, la solution la plus faible est d’échaffrager un projet neuf en mode cible et de copier vos personnalisations. Comparer votre hôte actuel à une référence fraîchement générée est aussi utile pour rechercher une divergence après un changement manuel.

Serveur → WebAssembly ou Auto

Ces étapes ajoutent WebAssembly à un hôte serveur uniquement. Les mêmes modifications s’appliquent que vous ciblez uniquement WebAssembly ou Auto — les seules différences sont les méthodes de construction que vous chaînez Program.cs et quels modes App.razor de rendu reviennent. Les deux sont signalés à chaque étape.

1. Convertir le . Projet client vers une application WebAssembly

Ouvrez .Client/MyApp.Client.csproj et changez le SDK de Microsoft.NET.Sdk.Razor . Microsoft.NET.Sdk.BlazorWebAssembly Ajoutez le framework WebAssembly et les packages clients Power Portals Pro :

Ajoutez également le paquet d’hébergement serveur WebAssembly à l’hôte .csproj serveur — il fournit le middleware qui sert le bundle WASM :

2. Enregistrer des composants WebAssembly interactifs sur le serveur

Dans le serveur Program.cs, remplacez l’enregistrement des composants par les appels builder correspondants. AddAuthenticationStateSerialization() sérialise l’utilisateur authentifié à travers la frontière Serveur→WASM afin que la cascade AuthenticationState soit cohérente sur les deux runtimes :

3. Cartographier le mode de rendu WebAssembly

Mise à jour app.MapRazorComponents<App>() pour enchaîner les terminaux de mode de rendu correspondants. L’appel AddAdditionalAssemblies pointe déjà vers les .Client assemblages _Imports dans les modèles, donc cela ne change pas ici :

4. Mettre à jour le PageRenderMode d’App.razor

Dans App.razorle getter PageRenderMode de , retournez le nouveau mode de rendu. Épinglez /Account/* d’abordInteractiveWebAssemblyRenderMode(prerender: false), puis retournez par défaut pour tout le reste :

Le broche Account-route est nécessaire car celui du IAuthService framework n’est enregistré que dans le graphe DI du client WASM. Sans le NIP, le prérendu côté serveur d’Auto ne se résout [Inject] IAuthService pas lors d’une session à froid.

5. Ajouter . Client/Program.cs

Créez un dans Program.cs le .Client projet. Cela configure l’hébergeur WebAssembly, enregistre le HttpClient site auprès du gestionnaire de transfert de cookies (donc des appels authentifiés du client WASM pour /api/* voir le même cookie d’authentification que le navigateur), et appelle AddPowerPortalsProWebClient pour enregistrer les services du cadre côté WASM. L’appel UserPowerPortalsProWebClient pré-récupère les chaînes de localisation de coupe croisée au démarrage afin que la première peinture ne flashe pas le texte clé comme solution de secours :

6. Passer du post-formulaire aux terminaux d’authentification JSON

Les hôtes serveurs utilisent MapAdditionalIdentityEndpoints() les pages d’identité de publication de formulaires. WebAssembly et les hôtes Auto utilisent MapAuthEndpoints<TUser>() à la place — le .Clientwrapper de 's IAuthService appelle ces terminaux JSON sous /api/auth/*:

Lorsque l’hôte exécute à la fois des pages de compte serveur et WASM (ce qui est rare), les deux enregistrements de terminaux peuvent coexister. Les modèles par défaut choisissent l’un ou l’autre en fonction du mode d’interactivité.

7. Déplacez les pages de compte vers le fichier . Projet client

Power Portals Pro propose deux ensembles parallèles de pages de compte, une pour chaque contexte de rendu :

8. Optionnel — gestionnaire d’exception à portée pour /api/*

Lorsque WebAssembly est en jeu, des exceptions sont lancées de /api/* la nécessité de faire un aller-retour vers le client WASM sous forme de problème RFC 9457 + json afin que le côté PowerPortalsProService client puisse réhydrater le type CLR original. Les modèles associent cela à un champ de vision UseExceptionHandler /api/* uniquement — la page d’exception développeur gère toujours les erreurs de page rendues par le serveur ailleurs :

WebAssembly ou serveur → automatique

Inversez les étapes ci-dessus :

Assemblage Web automatique ↔

Le switch le moins cher — la mise en page du projet, les paquets et les pages de compte sont identiques entre les deux. Seules trois choses changent :

Vérification du changement

Après avoir effectué les modifications :

Note

Faites attention aux incompatibilités service-durée de vie lors du transfert de services entre le serveur et le client WASM. L’hôte WASM fonctionne en un seul scope par session, mais les services de mise en cache du framework sont enregistrés comme singletons — si vous enregistrez votre propre service du Transient côté WASM, chaque état d’instance réinitialise silencieusement chaque résolution. Utilisez-le Singleton du côté WASM pour tout service qui détient un état mutable.