Interatividade Switch Blazor

Alternar um projeto existente do Power Portals Pro de um modo de interatividade para outro é uma série de edições em Program.cs, App.razor, no .Client projeto e (ao adicionar interatividade) nas páginas da Conta. A estrutura em si não precisa de nenhuma alteração — apenas a fiação do host precisa. Os passos abaixo cobrem as transições comuns.

Dica

Se suas personalizações ficam em poucas páginas, o caminho de menor atrito é estruturar um projeto novo no modo alvo e copiar suas personalizações. Comparar seu host atual com uma referência recém-gerada também é útil para buscar uma discrepância após uma troca manual.

Server → WebAssembly ou Auto

Esses passos adicionam WebAssembly a um host apenas para servidor. As mesmas edições se aplicam, seja você mirando apenas em WebAssembly ou Auto — as únicas diferenças são quais métodos de construtor você encadeia Program.cs e quais modos App.razor de renderização retornam. Ambos são chamados a cada passo.

1. Converter o . Projeto cliente para um aplicativo WebAssembly

Abra .Client/MyApp.Client.csproj e mude o SDK de Microsoft.NET.Sdk.Razor para Microsoft.NET.Sdk.BlazorWebAssembly. Adicione o framework WebAssembly e os pacotes clientes Power Portals Pro:

Adicione o pacote de hospedagem do lado do servidor WebAssembly também ao host .csproj do servidor — ele fornece o middleware que atende ao pacote WASM:

2. Registrar componentes interativos do WebAssembly no servidor

No servidor Program.cs, substitua o registro de componentes pelas chamadas de construtor correspondentes. AddAuthenticationStateSerialization() serializa o usuário autenticado através do limite Server→WASM para que a cascata AuthenticationState seja consistente em ambos os runtimes:

3. Mapear o modo de renderização do WebAssembly

Atualização app.MapRazorComponents<App>() para encadear os endpoints correspondentes ao modo de renderização. A AddAdditionalAssemblies chamada já aponta para as .Client assembleias _Imports nos modelos, então não muda aqui:

4. Atualizar o PageRenderMode do App.razor

Em App.razor's PageRenderMode getter, retorne o novo modo de renderização. Fixe /Account/* primeiro InteractiveWebAssemblyRenderMode(prerender: false)e depois retorne o padrão para todo o resto:

O pino Account-route é necessário porque o do framework IAuthService está registrado apenas no gráfico DI do cliente WASM. Sem o pin, o pré-render do lado do servidor do Auto não se resolve [Inject] IAuthService em uma sessão fria.

5. Adicionar . Cliente/Program.cs

Crie um Program.cs no .Client projeto. Isso configura o host WebAssembly, registra o HttpClient com o handler de encaminhamento de cookies (ou seja, chamadas autenticadas do cliente WASM para /api/* ver o mesmo cookie de autenticação do navegador) e chama AddPowerPortalsProWebClient para registrar os serviços do framework do lado WASM. A UserPowerPortalsProWebClient chamada pré-busca as strings de localização de corte cruzado na inicialização para que a primeira pintura não transmita texto com chave como recurso de recurso:

6. Mudança do post-formulário para endpoints de autenticação JSON

Os hosts de servidor usam MapAdditionalIdentityEndpoints() páginas de identidade de postagem de formulário. WebAssembly e Auto hosts usam MapAuthEndpoints<TUser>() em vez disso — o .Clientwrapper de 's IAuthService chama esses endpoints JSON sob /api/auth/*:

Quando o host executa páginas de Conta do Servidor e WASM (incomum), ambos os registros de endpoint podem coexistir. Os modelos padrão escolhem um ou outro com base no modo de interatividade.

7. Mover as páginas da Conta para o arquivo . Projeto do cliente

Power Portals Pro vem com dois conjuntos paralelos de páginas de conta, uma para cada contexto de renderização:

8. Opcional — tratador de exceções com escopo para /api/*

Quando o WebAssembly está em jogo, exceções são lançadas da /api/* necessidade de fazer ida e volta ao cliente WASM como problema RFC 9457 + json para que o lado PowerPortalsProService do cliente possa reidratar o tipo CLR original. Os templates conectam isso com um escopo UseExceptionHandler apenas para /api/* — a Página de Exceção do Desenvolvedor ainda lida com erros de página renderizados pelo servidor em outros lugares:

WebAssembly ou Servidor de → Automática

Inverta os passos acima:

Auto ↔ WebAssembly

O switch mais barato — o layout do projeto, pacotes e páginas de Conta são idênticos entre os dois. Apenas três coisas mudam:

Verificando a Mudança

Após fazer as mudanças:

Nota

Fique atento a desajustes entre serviço e vida útil ao mover serviços entre o servidor e o cliente WASM. O host WASM roda como um único escopo por sessão, mas os serviços de cache do framework são registrados como singletons — se você registrar seu próprio serviço como Transient do lado WASM, o estado por instância reinicia silenciosamente toda resolução. Use Singleton no lado WASM para qualquer serviço que mantenha estado mutável.