Interactividad Switch Blazor

Cambiar un proyecto existente de Power Portals Pro de un modo de interactividad a otro implica una serie de ediciones en Program.cs, App.razor, el .Client proyecto y (al añadir interactividad) las páginas de la Cuenta. El propio marco no necesita ningún cambio, solo el cableado del anfitrión. Los pasos siguientes cubren las transiciones más comunes.

Propina

Si tus personalizaciones están en un número reducido de páginas, el camino de menor fricción es andamiar un proyecto nuevo en el modo objetivo y copiar tus personalizaciones. Comparar tu host actual con una referencia recién generada también es útil para buscar una discrepancia tras un cambio manual.

Servidor → WebAssembly o Auto

Estos pasos añaden WebAssembly a un host solo de servidor. Las mismas modificaciones se aplican tanto si apuntas solo a WebAssembly como a Auto — las únicas diferencias son qué métodos de construcción encadenas Program.cs y qué modos App.razor de renderizado devuelves. Ambos se llaman por paso.

1. Convertir el . Proyecto cliente a una aplicación WebAssembly

Abre .Client/MyApp.Client.csproj y cambia el SDK de Microsoft.NET.Sdk.Razor a Microsoft.NET.Sdk.BlazorWebAssembly. Añadir el framework WebAssembly y los paquetes cliente Power Portals Pro:

Añade también el paquete .csproj de alojamiento WebAssembly en el servidor del servidor — proporciona el middleware que ofrece el paquete WASM:

2. Registrar componentes interactivos de WebAssembly en el servidor

En el servidor Program.cs, reemplaza el registro de componentes por las llamadas al constructor correspondientes. AddAuthenticationStateSerialization() serializa al usuario autenticado a través del límite Server→WASM para que la cascada AuthenticationState sea consistente en ambos tiempos de ejecución:

3. Mapear el modo de renderizado de WebAssembly

Actualización app.MapRazorComponents<App>() para encadenar los endpoints de modo de renderizado correspondientes. La AddAdditionalAssemblies llamada ya apunta a los .Client ensamblajes _Imports en las plantillas, así que aquí no cambia:

4. Actualizar el PageRenderMode de App.razor

En App.razor's PageRenderMode getter, devuelvo el nuevo modo de renderizado. Fija /Account/* primero InteractiveWebAssemblyRenderMode(prerender: false)y luego devuelve el valor predeterminado para todo lo demás:

El pin de ruta de cuenta es necesario porque el del framework IAuthService solo está registrado en el grafo DI del cliente WASM. Sin el pin, el prerenderizado del servidor de Auto no se resuelve [Inject] IAuthService en una sesión en frío.

5. Añadir . Cliente/Program.cs

Crea una Program.cs en el .Client proyecto. Esto configura el host WebAssembly, se HttpClient registra con el gestor de reenvío de cookies (es decir, llamadas autenticadas desde el cliente WASM para /api/* ver la misma cookie de autenticación que el navegador) y llama AddPowerPortalsProWebClient para registrar los servicios del framework del lado WASM. La UserPowerPortalsProWebClient llamada prerecoge las cadenas de localización de corte cruzado al inicio, así que la primera pintura no parpadea el texto clave como respaldo:

6. Cambiar de post-formulario a endpoints de autenticación JSON

Los servidores de servidores se utilizan MapAdditionalIdentityEndpoints() para páginas de identidad de publicación de formularios. WebAssembly y los hosts Auto usan MapAuthEndpoints<TUser>() en su lugar — el .Clientwrapper de 's IAuthService llama a estos extremos JSON bajo /api/auth/*:

Cuando el host ejecuta tanto páginas de cuenta de servidor como de WASM (poco común), ambos registros de endpoint pueden coexistir. Las plantillas predeterminadas eligen una u otra según el modo interactivo.

7. Mover las páginas de la cuenta a la . Proyecto del cliente

Power Portals Pro incluye dos conjuntos paralelos de páginas de cuenta, una para cada contexto de renderizado:

8. Opcional — gestor de excepciones con alcance para /api/*

Cuando WebAssembly está en juego, se lanzan excepciones desde /api/* la necesidad de hacer el viaje de ida y vuelta al cliente WASM como problema RFC 9457+json para que el lado PowerPortalsProService del cliente pueda rehidratar el tipo CLR original. Las plantillas conectan esto con un ámbito UseExceptionHandler /api/* solo — la Página de Excepciones para Desarrolladores sigue gestionando errores de página renderizadas por el servidor en otros lugares:

WebAssembly o servidor de → automática

Invierte los pasos anteriores:

Ensamblaje Web Automático ↔

El switch más barato — el diseño del proyecto, los paquetes y las páginas de cuenta son idénticos entre ambos. Solo cambian tres cosas:

Verificación del cambio

Después de hacer los cambios:

Nota

Ten cuidado con las diferencias entre servicio y vida útil al mover servicios entre el servidor y el cliente WASM. El host WASM funciona como un único ámbito por sesión, pero los servicios de caché del framework se registran como singletons — si registras tu propio servicio como Transient en el lado WASM, el estado por instancia reinicia silenciosamente cada resolución. Úsalo Singleton en el lado WASM para cualquier servicio que mantenga estado mutable.