Blazor - Interatividade Global e por página

  Hoje vou apresentar as diferenças entre a Interatividade Global e a Por página/ componentes no template Blazor Web App.

O  template unificado Blazor Web App introduzido no .NET 8 (e aprimorado no .NET 9) trouxe um novo modelo de desenvolvimento com renderização híbrida, permitindo que páginas e componentes sejam renderizados de forma estática (SSR) ou interativa (nteractive Server, Interactive WebAssembly ou Interactive Auto.

Ao criar um novo projeto usando esse template, você pode escolher:

- Render Mode: define como e onde o componente será renderizado, podendo utilizar Static SSR, Interactive Server, Interactive WebAssembly ou Interactive Auto;

- Interactivity Location: define onde a interatividade será aplicada, podendo ser Global ou Per Page/Component

Assim podemos ter :

Global + Interactive Server
Global + Interactive WebAssembly
Global + Interactive Auto

e também

Per Page/Component + Interactive Server
Per Page/Component + Interactive WebAssembly
Per Page/Component + Interactive Auto

Neste artigo, vamos explorar as diferenças práticas entre as opções "Interactivity Location: Global" e "Per Page/Component", destacando como isso afeta a estrutura do projeto, a organização dos componentes e o fluxo de execução.

O que é Interatividade no Blazor Web App?

A interatividade no Blazor define se e como um componente permite ações do usuário como cliques, formulários, binding e chamadas assíncronas.

Static SSR → apenas HTML renderizado no servidor, sem interatividade.
Interactive Server → interatividade via SignalR.
Interactive WebAssembly → interatividade executada no navegador com WebAssembly.
Auto → Inicialmente utiliza Interactive Server e, depois que o runtime e o bundle são baixados e armazenados em cache, pode utilizar WebAssembly em visitas futuras;

Diferença entre os dois modos

1. Interactivity Location: Global

O render mode global é aplicado automaticamente a todos os componentes renderizados por <Routes> no arquivo App.razor

Neste modo, toda a aplicação é interativa por padrão — ou seja, você não precisa definir @rendermode em cada componente.

Esse é o modo que a Microsoft recomenda para SPAs modernas com interatividade em todo lugar, e isso usa Blazor WebAssembly por padrão no navegador, mas com fallback para Blazor Server.

Ele é Ideal para quem está migrando de projetos Blazor Server ou Blazor WASM tradicionais.

<!DOCTYPE html>
<html lang="en">

<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<base href="/" />

<link href="https://fonts.googleapis.com/css?family=Roboto:300,400,500,700&display=swap" rel="stylesheet" />
<link href="_content/MudBlazor/MudBlazor.min.css" rel="stylesheet" />


<link rel="icon" type="image/png" href="favicon.ico" />
<HeadOutlet @rendermode="@InteractiveAuto" />
</head>

<body>
<Routes @rendermode="@InteractiveAuto" />
<script src="_framework/blazor.web.js"></script>
<script src="_content/MudBlazor/MudBlazor.min.js"></script>
</body>

</html>

Esta linha de código :  <Routes @rendermode="@InteractiveAuto" />  define que:

As páginas roteadas pelo <Routes> herdam o modo de renderização definido no componente Routes, salvo quando a aplicação configura explicitamente uma página ou área para permanecer em SSR estático.

Assim, se o projeto cliente for WebAssembly, o navegador executará os componentes client-side.
Se não for possível usar WebAssembly, ele usa Blazor Server como fallback que significa que se o Blazor WebAssembly não puder ser executado no navegador do usuário, a aplicação automaticamente recorre (ou "cai") para o modo Blazor Server.

2. Interactivity Location: Per Page/Component

Neste modo, a interatividade é definida pontualmente, ou seja, você deve usar @rendermode manualmente em cada página ou componente que quiser tornar interativo.

-  Ideal para aplicações mistas, onde parte do conteúdo pode ser estático (SSR puro) e partes específicas (como formulários) são interativas.

Assim podemos ter: 

 Diferença na Estrutura dos Projetos

1- No modo Global com Interactive Server é gerado apenas um único projeto (não há projeto .Client, pois tudo roda no servidor).

2- Com Interactivity Location: Global a e interactive render mode Auto, estrutura do projeto criado é a seguinte:

O projeto Client -  BlazorApp.Client  - contém tudo: páginas, layouts, navegação, renderização.
A aplicação é interativa por padrão (usa InteractiveServer ou Auto).
Você não precisa usar @rendermode nos componentes.
A renderização é feita no lado client usando Blazor Server ou WASM.

3- Com Interactive render mode Auto e Interactivity Location: Per page/Component a estrutura do projeto criado é a seguinte:

O projeto principal - BlazorApp2 - é responsável por toda a estrutura visual e páginas estáticas SSR.

O projeto BlazorApp2.Client contém apenas os componentes que terão interatividade (ex: Counter.razor). Ele é o projeto que permite a execução de componentes no WebAssembly, portanto é utilizado quando você escolhe InteractiveWebAssembly ou InteractiveAuto.

Agora, você precisa adicionar @rendermode nos componentes que devem ser interativos

A nova estrutura do Blazor Web App pode parecer confusa à primeira vista, principalmente porque o Visual Studio gera projetos bem diferentes dependendo das escolhas feitas no assistente de criação.

Porém, entender essas diferenças é fundamental para tirar o máximo proveito do Blazor moderno:

1-) Interactivity Global é ideal para começar com o Blazor de forma tradicional.

2-) Per Page/Component oferece maior controle sobre onde a interatividade será utilizada e permite combinar SSR estático com componentes interativos, podendo reduzir o custo de interatividade em aplicações onde apenas algumas partes precisam ser interativas.

Dominar essas opções é o primeiro passo para construir aplicações web modernas, rápidas e responsivas com .NET!

E estamos conversados...

"Ó, vinde, adoremos e prostremo-nos; ajoelhemos diante do Senhor que nos criou."
Salmos 95:6

Referências:

José Carlos Macoratti