ASP .NET Core - Criando uma SPA Blazor com VS Code II

Hoje vamos criar uma aplicação SPA a partir de uma projeto ASP .NET Core vazio usando os recursos do Blazor.

Se você esta chegando agora e não sabe o que é o Blazor leia o artigo ASP .NET Core - Iniciando com o Blazor - Macoratti; se você já conhece e quer saber mais pode fazer o meu curso de Blazor Essencial.

Continuando a primeira parte do artigo veremos agora como criar uma aplicação SPA usando a hospedagem WebAssembly.

Criando uma aplicação SPA Blazor WebAssembly

Vamos repetir o procedimento adotado no primeiro artigo e iniciar criando uma aplicação SPA a partir de um projeto ASP .NET Core usando o template Empty.

Abra um terminal de linha de comandos, e digite o comando : dotnet new web -o contador-wasm

Isso vai criar um projeto ASP .NET Core Web vazio na dentro da pasta contador-wasm:

Para abrir no VS Code basta entrar na pasta contador-wasm e digitar: code .

A seguir vamos abrir o arquivo de projeto contador-wasm.csproj:

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <RootNamespace>contador_wasm</RootNamespace>
  </PropertyGroup>

</Project>

A primeira coisa a dizer é que o resultado de um build Blazor WebAssembly não é um aplicativo da ASP .NET clássico.
Em vez disso, ele é um conjunto de arquivos que o navegador fará o download e executará localmente. O servidor web, Kestrel no nosso caso, é apenas uma maneira de expor este conjunto de arquivos para o navegador.

Precisamos alterar este arquivo de projeto conforme abaixo:

<PropertyGroup>
<TargetFramework>netstandard2.1</TargetFramework>
<RazorLangVersion>3.0</RazorLangVersion>
</PropertyGroup>

</Project>

A primeira diferença que você deve observar é a alteração do TargetFramework para netstandard2.1; isso permite a o build do projeto com as dependências corretas. Também precisamos definir a versão do Razor (RazorLangVersion) para a versão 3.0 para permitir a construção de Componentes Razor.

Finalmente, com o elemento ItemGroup, declaramos todos as dependências para a construção e execução do engine Blazor WebAssembly.

Agora vamos alterar o código do método Main(), abra o arquivo Program.cs e exclua o arquivo estático CreateHostBuilder(), porque o framework nos fornece uma API simples para iniciar o Kestrel diretamente no método Main :

using System.Threading.Tasks;
using Microsoft.AspNetCore.Components.WebAssembly.Hosting;

namespace contador_wasm
{
    public class Program
    {
        public static async Task Main(string[] args)
        {
            var builder = WebAssemblyHostBuilder.CreateDefault(args);
                  builder.RootComponents.Add<Contador>("contador");
                      await builder.Build().RunAsync();
        }   
    }
}

Aqui precisamos de apenas três linhas de código para configurar a hospedagem de um aplicativo WebAssembly:

Criar um WebAssemblyHostBuilder com os parâmetros padrão;
Definir o componente Contador como o componente Rooy;
Começar a ouvir solicitações HTTP no aplicativo;

Com isso não vamos precisar definir nada no método ConfigureServices nem no método Configure que pode ser até removido. Assim nossa classe Startup pode ficar assim:

using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.DependencyInjection;

namespace contador
{
    public class Startup
    {
        public void ConfigureServices(IServiceCollection services)
        {
        }
    }
}

Vamos criar o componente Contador.razor na raiz do projeto e vamos usar o mesmo código do artigo anterior:

@using Microsoft.AspNetCore.Components.Web
@using System.Timers;

<h1>Contador Blazor</h1>

<p>@contar</p>

<button @onclick="IniciaContagem">Iniciar</button>

@code {
    private int contar = 0;

    private void IniciaContagem()
    {
         contar = 10;

         Timer timer = new Timer (1000);

         timer.Elapsed += (source, e) => 
         {
              contar--;
              InvokeAsync(() => StateHasChanged());
              if (contar == 0) timer.Stop ();
         };
         timer.Start ();
    }
}

Agora precisamos renderizar este componente Blazor no lado do cliente e não temos um arquivo _Host.cshtml.

Nas aplicações Blazor WebAssembly, podemos criar um arquivo Index.html na pasta wwwroot que vai atuar da mesma forma que o arquivo _Host.cshtml.

Assim vamos criar a pasta wwwroot na raiz do projeto e nesta pasta vamos criar o arquivo Index.html com o código abaixo:

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8" />
  <meta name="viewport" content="width=device-width" />
  <title>Contador</title>
</head>
<body>
  <contador>Carregando...</contador>
  <script src="_framework/blazor.webassembly.js"></script>
</body>
</html>

Temos aqui um arquivo HTML onde estamos definindo o elemento <contador></contador> onde será renderizado o nosso componente Blazor Contador.razor.

Durante a análise da página, o navegador ignora o elemento <contador> porque ele não é um elemento HTML5 válido, mas depois de carregar o script blazor.webassembly.js, o componente Blazor é reconhecido e será
executado.

E isso é tudo.

Agora basta digitar dotnet run na janela de comandos e executar o projeto para ter o mesmo comportamento.

Temos assim uma aplicação SPA usando o Blazor WebAssembly a partir de um projeto ASP .NET Core.

Na execução o código será executado no navegador que pode executar o código .NET das DLLs do projeto usando
a portabilidade do WebAssembly do framework Mono.

O arquivo contador-wasm.dll contém nosso código compilado em Intermediate Language (IL) executado pelo Mono no navegador com os arquivos dotnet.wasm e dotnet.js. O aplicativo usa várias DLLs da plataforma .NET também baixadas no navegador, incluindo o Blazor, que interagem com o ambiente graças ao script blazor.webassembly.js.

Todas as bibliotecas de DLLs e os componentes do runtime são armazenados em cache no navegador, para que não sejam baixados na próxima execução do aplicativo.

Vimos assim a apresentação do Blazor Server e do Blazor WebAssembly.

Qual versão do Blazor é a melhor para a sua aplicação ?

Que critérios você deve usar ao escolher entre Blazor Server e Blazor WebAssembly ?

Quando comparamos o tempo de carregamento, o Blazor Server é mais rápido que o WebAssembly porque é executado no lado do servidor e, portanto, o tamanho do download é menor.

Por outro lado, um aplicativo Blazor WebAssembly é executado completamente no navegador e fornece uma experiência Single Page Application ao usuário do aplicativo contra uma carga inicial mais pesada.

Se seu aplicativo for completamente executado no lado do cliente, você poderá suportar um cenário offline, porque não é necessário chamar o servidor para todas as atualizações da interface do usuário. Por outro lado, se você precisar armazenar informações sensíveis um aplicativo de servidor permite armazená-lo com mais segurança, pois o usuário não tem acesso direto aos dados.

Por fim, o suporte ao navegador do WebAssembly pode ser um motivo para escolher o Blazor Server, pois ainda existem muitos aplicativos que precisam ser executados no Internet Explorer, por exemplo, onde o suporte para o novo padrão não esta disponível.

Pegue o projeto aqui : contador-wasm.zip (sem as referências)

"Portanto, cingindo os lombos do vosso entendimento, sede sóbrios, e esperai inteiramente na graça que se vos ofereceu na revelação de Jesus Cristo;"
1 Pedro 1:13

Referências:

José Carlos Macoratti