Blazor - Os novos modos de renderização no .NET 8 - II
Hoje vamos continuar os novos modos de renderização presentes no .NET 8.0 e como usá-los em projetos Blazor. |
Continuando o artigo anterior vamos vamos apresentar os modos de renderização Interactive WASM e interactive Auto.
Interactive WebAssembly (WASM)
A outra opção para habilitar a interatividade é usar o Blazor WebAssembly (WASM). A diferença é que o componente será executado no cliente (no navegador) e não no servidor.
Podemos configurá-lo na chamada do site (quando renderizamos uma instância do componente) temos o código a seguir:
<Banner Text="Olá Mundo !" @rendermode="@RenderMode.InteractiveWebAssembly /> |
Ou podemos fazer isso no próprio componente:
@rendermode RenderMode.InteractiveWebAssembly @code { [Parameter] public string? Text { get; set; } [Parameter] public string BackgroundColor { get; set; } = "lightblue"; [Parameter] public string TextColor { get; set; } = "black"; } <div style="background-color: @BackgroundColor; color: @TextColor; padding: 1rem; text-align: center; border: 1px solid #ccc; border-radius: 0.5rem; margin: 1rem 0;"> @Text </div> |
No entanto, tente fazer isso com um componente aleatório do seu aplicativo
Blazor e é provável que não vai funcionar.
Isso ocorre porque o modo
Interactive WASM exige que você arquitete seu aplicativo de uma maneira
específica.
Como ativar a renderização WebAssembly
Como nos demais modos de renderização podemos ativar este modo na classe Program :
Program.cs |
Você também precisa colocar todos os componentes que deseja executar dessa
maneira em um projeto cliente separado.
Logicamente, isso faz sentido, já
que você não deseja que todo o seu aplicativo de servidor seja enviado para o
navegador o que não faz
sentido para um aplicativo cliente em execução no navegador.
Como funciona ?
Assim que o navegador tiver o aplicativo, ele poderá localizar o componente
relevante (Banner, neste caso) e renderizá-lo ali mesmo no navegador.
Então, quando alguém clica em um botão, o evento onclick é tratado pelo
componente em execução no navegador. O .NET (no navegador) intercepta o evento
onclick, encaminha-o para o componente relevante, renderiza novamente e atualiza
o DOM de acordo.
A boa notícia é que o grande download inicial só precisa acontecer uma vez, independentemente de quantos componentes do seu aplicativo são executados usando o WASM interativo.
Para que serve ?
O diferencial do WASM é sua capacidade de executar no modo
semi-desconectado (pode ser executado no navegador sem conectar-se
constantemente a um servidor).
Também é bom para permitir a
interatividade em sites voltados para o consumidor e em outros sites onde a
interatividade é necessária, mas é melhor evitar a UX em torno de conexões de
soquete perdidas.
Vantagens
A grande vantagem do WASM interativo é que você obtém
componentes totalmente interativos sem a necessidade de lançar recursos do
servidor em seu aplicativo. Com esses componentes em execução no navegador, você
permite que seus usuários assumam o poder de processamento.
As
interações com um componente renderizado usando o Interactive Server podem estar
sujeitas a atrasos (já que leva tempo para as solicitações irem e voltarem
ao servidor), aqui tudo está acontecendo no navegador e assim a experiência
para o usuário é muito mais tranquila.
Seus componentes também podem
rodar “offline” neste modo, já que tudo está rodando no navegador (embora
você precise dessa conexão de rede para buscar ou atualizar dados no servidor).
Desvantagens
Para alguns tipos de aplicativos, o grande download
inicial do tempo runtime do .NET e do seu aplicativo pode representar um
desafio, pois atrasa o carregamento inicial de uma página.
Como seu
aplicativo está sendo executado no navegador, você precisará criar uma API para
lidar com as interações com os recursos do servidor.
A exigência de armazenar seus componentes em um
projeto separado adiciona alguma complexidade ao seu aplicativo, mas você também
pode precisar de um projeto compartilhado para armazenar modelos compartilhados
entre servidor e cliente (DTOs, por exemplo).
Interactive Auto
Finalmente, há mais uma maneira de renderizar seus
componentes: usando o modo automático.
Com isso, seu componente pode usar
o Blazor Server inicialmente (enquanto os arquivos do Blazor Web Assembly
são baixados em segundo plano) e, em seguida, usar o Blazor WASM para
solicitações subsequentes.
Isso permite que você use o carregamento
inicial rápido do Blazor Server para evitar que os usuários esperem pelo
carregamento e inicialização do WASM, mas ainda use o WASM para a maioria das
interações contínuas (reduzindo assim a carga do seu servidor e evitando
alguns dos problemas complicados de UX com o Blazor Server desconexões, etc.)
<Banner2 Texto="Olá Mundo" @rendermode="@RenderMode.InteractiveAuto" /> |
Também podemos fazer esta configuração no próprio componente ou na chamada do site:
@page "/" @rendermode RenderMode.InteractiveAuto |
Como ativar a renderização
automática
Você precisará ter os modos Servidor e WASM configurados em seu
Program.cs.
Program.cs |
A seguir você pode configurar qualquer componente para usar o modo automático (desde que esteja localizado no projeto do seu cliente).
Como funciona o modo Auto ?
A primeira solicitação para uma página com um componente
definido para ser executado neste modo usará o Blazor Server. Em segundo plano, o navegador irá baixar e
iniciar o Blazor WebAssembly.
Na próxima vez que o usuário visitar uma
página com um componente definido para ser executado no modo Interactive Auto,
ele usará o Blazor WASM em vez do Server.
Para que serve ?
Permitir interatividade para a maioria dos tipos de site, como
páginas de destino, aplicativos de linha de negócios e aplicativos voltados para
o consumidor. Basicamente, tudo o que o Server/WASM é adequado quando usado
separadamente.
Vantagens
A grande vantagem aqui é que você pode evitar o desafio de fazer
seus usuários esperarem pelo Blazor WASM (usando o Server inicialmente), mas
ainda usar o WASM para a maioria das interações posteriores.
O resultado
é uma carga muito mais leve para seu servidor e uma experiência de usuário mais
rápida para seus usuários.
Desvantagens
Com Há mais complexidade inerente ao projetar seus
componentes para serem executados em vários modos de renderização. Você
precisará ter certeza de que eles podem ser executados no servidor e no cliente.
Você precisará usar uma API da Web entre o componente e seus dados/lógica de
back-end para garantir que ele possa ser executado no cliente. Se não quiser
usar a API Web no modo Servidor, você precisará criar abstrações para lidar com
as duas maneiras diferentes de interagir com os recursos do servidor (novamente,
isso adiciona complexidade ao seu aplicativo).
Desta forma os modos de renderização do NET 8 tornam o Blazor uma opção para a maioria dos tipos de aplicativos da web.
Para páginas “simples” (páginas de destino, visualizações somente leitura), a renderização estática do lado do servidor é rápida, eficiente e simples de implementar.
Para algo mais interativo, o Blazor Server representa a opção de “atualização” mais fácil. Normalmente, você pode pegar um componente executado no modo SSR estático e alterná-lo para usar o Interactive Server.
Para facilitar o seu servidor (e evitar problemas de UX em torno de desconexões de soquete), você pode adotar o modo WASM interativo - apenas esteja ciente de que isso tem implicações para a arquitetura do seu site.
E estamos conversados...
"O Senhor é a minha força e o meu escudo; nele confiou o
meu coração, e fui socorrido; assim o meu coração salta de prazer, e com o meu
canto o louvarei."
Salmos 28:7
Referências:
Domain Drive Design - Resumo do Livro de Eric ..
DDD – Introdução a Domain Driven Design
Desmistificando o DDD