Blazor  - Os novos modos de renderização no .NET 8 - I

Hoje vamos apresentar os novos modos de renderização presentes no .NET 8.0 e como usá-los em projetos Blazor.

Antes do .NET 8, você normalmente executava todo o seu aplicativo Blazor usando um dos modelos de hospedagem do Blazor: Blazor WASM ou Blazor Server.

Com o Blazor Server, seus componentes são executados no servidor e todas as interações da UI entre o navegador e o servidor ocorrem por meio de uma conexão via socket.

No Blazor WASM, todo o seu aplicativo é enviado para o navegador onde é executado e todas as interações da IU são tratadas ali mesmo, no navegador.

A partir do .NET 8 temos outras opções e agora temos a capacidade de controlar por componente como os nossos componentes serão executados, alterando o que é chamado modo de renderização ou render mode.

O Atualmente existem os seguintes modos de renderização no .NET 8.0 :

- Static Server-Side
- Interactive Server
- Interactive WASM
- Interactive Auto

Mas o que são eles, quais são seus pontos fortes e fracos e quais deles você deve usar ?

Static Server-Side - Renderização estática do lado do servidor

Ao criar um novo projeto usando o template de projeto do .NET 8 Blazor: dotnet new blazor -o AppBlazor1

Vamos obter um aplicativo Blazor conectado para renderizar componentes estaticamente no servidor por padrão. Por exemplo, se tivermos um componente Banner com o seguinte código:

@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>

E usarmos este componente em um novo projeto Blazor .NET 8 referênciando-o no componente Home.razor desta forma :

<Banner Text="Olá Mundo !" TextColor="Yellow" BackgroundColor="Black"></Banner>

Quando executarmos o projeto e verificarmos os resultados no navegador, veremos o banner sendo exibido, e, se espiarmos o código usando a Ferramentas do Desenvolvedor (Chrome) veremos uma solicitação/resposta completa do documento, contendo o HTML que é exibido no navegador.

Como ativar a renderização estática do lado do servidor

Ao criar um projeto Blazor usando o novo template de projeto do .NET 8, você pode escolher quais modos de renderização deseja usar.  Observando o código gerado no arquivo Program.cs veremos a seguinte configuração como resultado.

builder.Services.AddRazorComponents();

...
    
app.MapRazorComponents<App>();

Para que a renderização estática funcione, o mínimo necessário são duas chamadas para AddRazorComponents e MapRazorComponents<App>().

Como funciona ?

A ASP.NET vai encaminhar as solicitações recebidas para qualquer componente Razor que tenha um modelo de rota correspondentee, e, a seguir ela renderizará o componente e retornará o HTML resultante.

A renderização estática do lado do servidor é útil em cenários onde os componentes não precisam ser interativos.

Contanto que você não espere que os usuários possam interagir por meio de cliques em botões, alternâncias deslizantes, etc., esse modo é simples e rápido e não exige que o componente viva por mais tempo do que a resposta HTML leva para ser renderizada e devolvida.

Desta forma este modo de renderização é útil para sites onde a exibição de informações é fundamental, como páginas de destino, páginas de produtos online, gráficos não interativos, etc.

Vantagens

A renderização estática do lado do servidor é simples, sem componentes de longa execução ou estado de componente para se pensar.

A ASP.NET trata a solicitação recebida, renderiza o componente e, em seguida, descarta-o imediatamente. Se você está acostumado a construir aplicativos web usando Razor Pages ou MVC, usando componentes Razor, essa abordagem será muito semelhante.

Desvantagens

Como os componentes resultantes são renderizados estaticamente, você não pode conectar manipuladores de eventos a eventos DOM, como o clique do usuário em um botão.

Para alguma interatividade, você pode usar renderização estática e formulários (para capturar a entrada do usuário), mas qualquer interatividade mais avançada (como cliques em vários botões, controles deslizantes, lógica de negócios dinâmica) exigiria um dos outros modos.

Nesse modo, seu aplicativo não está sendo executado como um aplicativo de página única (SPA), portanto, você não pode manter o estado na parte da IU do seu aplicativo por nenhum período de tempo. Seus componentes ficam ativos apenas pelo tempo necessário para renderizar e retornar o HTML para qualquer solicitação.

Interactive Server - Interatividade do lado do servidor

Se você precisa que seus componentes sejam mais interativos, uma opção é executá-los usando o Blazor Server com interatividade no servidor.

Digamos, por exemplo, que implementemos um componente Banner2.razor contendo um botão para descartar o banner conforme o código abaixo:

@if(!descartar)
{
    <div class="border p-4 d-flex 
                            justify-content-between align-items-start 
                            bg-primary text-white"> 
        <p class="fs-2">
            @Texto
        </p> 
        <button @onclick="()=>descartar=true">
            X
        </button>       
    </div>
}
@code {
    [Parameter]
    public string? Texto { get; set; }

    bool descartar;    
}

Este código não funcionará no modo de renderização estática. O usuário poderia clicar no botão X quantas vezes quiser e nada vai acontecer !

Mas podemos fazer com que isso funcione se executarmos o componente no modo Interactive Server, o que podemos fazer através do atributo rendermode:

<Banner2 Texto="Banner interativo" @rendermode="@RenderMode.InteractiveServer" />

Com isso o componente Banner será renderizado usando o Blazor Server com interatividade.

Também podemos fazer esta configuração no próprio componente Home.razor (para que o padrão seja executado usando o Interactive Server).

Executando o projeto novamente iremos obter:

Examinando a opção Ferramentas de desenvolvimento no Chrome veremos que temos uma conexão de soqete aberta :

E ao clicar no botão para descartar o banner, ele será descartado.

Como ativar a renderização interativa do servidor

Tal como acontece com todos os modos de renderização, podemos ativar o modo de renderização do Servidor Interativo definindo o seguinte código em Program.cs :

builder.Services.AddRazorComponents().AddInteractiveServerRenderMode();

...
    
app.MapRazorComponents<App>().AddInteractiveServerRenderMode();

Como funciona ?

Este modo funciona basicamente da mesma forma que o Blazor Server sempre funcionou, usando conexões de soquete para lidar com a comunicação entre o cliente (navegador) e o servidor.

- O evento onclick será enviado pela conexão de soquete para o servidor.
- O Blazor em execução no servidor encaminhará esse evento para o componente relevante e executará o manipulador relevante.
- O componente será renderizado novamente.
- Uma comparação DOM será enviada ao navegador.
- O navegador atualiza de forma inteligente as partes do DOM que foram alteradas.

Para que serve ?

O modo Interactive Server é uma maneira fácil de ativar a interatividade para seu aplicativo.

Aplicativos de linha de negócios, relatórios/grades/controles deslizantes interativos, etc. podem ser gerenciados por meio do Interactive Server.

Vantagens

É fácil pegar um componente existente (que está sendo renderizado estaticamente) e trocá-lo para usar o modo Interactive Server. Na maioria dos casos, basta definir o atributo rendermode para o componente.

Como o componente ainda está em execução no servidor, você não precisa introduzir uma API Web para lidar com solicitações (seus componentes podem chamar a lógica de negócios e/ou conectar-se aos dados diretamente).

A partir do .NET 8, os circuitos do servidor Blazor são desconectados automaticamente quando não são mais necessários. Neste caso, se navegássemos para uma página diferente sem componentes interativos do servidor, a conexão do soquete subjacente seria desconectada após um curto período de tempo, reduzindo assim a carga no servidor.

Desvantagens

Com este modo, cada interação é enviada através da conexão web socket para o seu servidor, que deve monitorar todos os componentes “ativos”.

Isso significa que seu servidor precisa ser capaz de lidar com a carga e, se seu site se tornar mais popular, você precisará investir em mais recursos de servidor.

Se a conexão entre o navegador e o servidor for perdida (por qualquer motivo), uma mensagem de erro será exibida e o aplicativo efetivamente parará de funcionar.

Por esse motivo, é importante considerar onde você está armazenando o estado do aplicativo, pois qualquer problema transitório de rede (ou reimplantação) provavelmente forçará o usuário a recarregar o aplicativo (e perder qualquer estado existente que não persistiu em outro lugar, como um banco de dados).

Na próxima parte do artigo veremos os outros dois modos de renderização.

E estamos conversados...  

"O Senhor é o meu rochedo, e o meu lugar forte, e o meu libertador; o meu Deus, a minha fortaleza, em quem confio; o meu escudo, a força da minha salvação, e o meu alto refúgio."
Salmos 18:2

Referências:

• Minimal Apis com Dapper

• Apresentando o Dapper (vídeo)

• Asp.NET Core - CRUD com Dapper e padrão Repository

• Dapper Básico

• Dapper Tutorial

• Domain Drive Design - Resumo do Livro de Eric ..

• DDD – Introdução a Domain Driven Design

• Desmistificando o DDD

José Carlos Macoratti