Se você tem acompanhado os últimos desenvolvimentos no mundo .NET ao longo do último ano ou dois, você provavelmente já ouviu a palavra Blazor mencionada uma ou duas vezes. Blazor é uma nova estrutura de interface do cliente da equipe ASP.NET. Seu grande ponto de venda é a capacidade de escrever experiências ricas de Interface web usando HTML, CSS e C# em vez de JavaScript — algo que muitos desenvolvedores têm sonhado.

Embora o JavaScript tenha sido o padrão de fato para o desenvolvimento front-end da Web desde o seu início, nunca pareceu realmente estar felizes com ele. Quero dizer, quantos superconjuntos ou transpilos para linguagens JavaScript surgiram ao longo dos anos para ajudar a melhorar o JavaScript e torná-lo mais mantenedor? CoffeeScript, Dardo, Elm e Scala — para citar apenas alguns.

Olhando para as línguas mais amadas, TypeScript, uma linguagem projetada pelo lendário Anders Hejlsberg,lidera a lista. O mesmo homem que projetou C#, nada menos. Ele adiciona recursos como interfaces, classes, compilar verificação de tipo de tempo, até mesmo genéricos. No entanto, todas essas características e mais já existem em C#, e têm feito por anos. C# é uma linguagem poderosa, flexível e rica que é fácil de aprender.

Mas a Blazor já começou a mostrar que tem potencial como um modelo de programação altamente eficiente e produtivo fora de seu design original — como um concorrente direto para as estruturas de spa (Single Page Application, aplicativo de página única) JavaScript.

A Microsoft já tem vários experimentos acontecendo com Blazor, testando-o com aplicativos de desktop usando Electron e WebWindow (uma alternativa experimental leve à Electron). Mas, mais recentemente, para o desenvolvimento de aplicativos móveis nativos, onde o modelo de programação Blazor é misturado com controles de formas xamarin nativas.

Poderíamos estar vendo o início de uma única estrutura de interface do usuário unificada para construir qualquer tipo de aplicativo com .NET, seja web, desktop ou celular? Não sei quanto a você, mas acho isso uma perspectiva excitante.

 

O que torna Blazor tão flexível?

 

Para responder a essa pergunta, precisamos entender como Blazor foi arquitetado.

 

Essencialmente, Blazor tem uma separação entre como ele calcula as alterações de interface do usuário (modelo de aplicativo/componente) e como essas alterações são aplicadas (renderizador). Isso diferencia o Blazor de outras estruturas de interface do usuário, como angular ou ReactJS/React Native, que só podem criar UIs baseados em tecnologia web. Usando diferentes renderizadores, o Blazor é capaz de criar não apenas UIs baseados na Web, mas também uis móveis nativos.

Isso requer que os componentes sejam de autoria de forma diferente, de modo que os componentes escritos para renderizadores web não podem ser usados com renderizadores móveis nativos. No entanto, o modelo de programação é o mesmo. Ou seja, uma vez que os desenvolvedores estão familiarizados com ele, eles podem criar UIs usando qualquer renderizador.

 

Modelo de renderização/hospedagem

 

Em sua essência, o modelo de aplicativo/componente da Blazor é responsável pelo cálculo das alterações da interface do usuário, mas você pode usar diferentes renderizadores para controlar como a interface do usuário é realmente exibida e atualizada. Essas renderizadores são mais comumente referidas como modelos de hospedagem. No momento da escrita, há quatro modelos de hospedagem para Blazor em várias etapas de desenvolvimento.

 

Servidor Blazor (Renderizador Remoto)

 

 

Plataforma: Web

 

Status – GA/Produção Suportada

 

Blazor WebAssembly (WebAssembly Renderer)

 

Plataforma: Web

 

Status: Visualização (Produto Comprometido)

 

Elétron Blazor (Renderizador de Elétrons)

 

Plataforma: Desktop (Windows, Mac e Linux)

 

Status: Experimental (Não Comprometido)

 

Ligações Blazor Móvel (MobileBlazorBindings Renderer)

 

Plataforma: Mobile (iOS e Android)

 

Status: Experimental (Não Comprometido)

 

Blazor Server é o único modelo suportado pela produção no momento da escrita. Blazor WebAssembly deve ser lançado por volta de maio de 2020 — eu esperaria que este pudesse ser o grande anúncio na Build. Blazor Electron e Mobile Blazor Bindings são marcados como experimentais e a Microsoft ainda não se comprometeu a enviá-las.

 

Modelo de aplicativo/componente

 

Esta é a sala de máquinas da estrutura. Aqui podemos encontrar todos os elementos específicos não-UI que fazem Blazor funcionar. O modelo de programação, roteamento e navegação, e a árvore de renderização, que é o mecanismo de Blazor para calcular as alterações de interface do usuário.

A parte que quero focar é no modelo de programação. Dos quatro modelos de hospedagem que falei acima, os três primeiros têm uma coisa em comum, todos entendem os padrões da web. Os componentes de autoria para segmentar esses modelos de hospedagem usarão HTML e CSS. Mas o quarto modelo, Mobile Blazor, não entende os padrões da Web. Os aplicativos construídos para este modelo de hospedagem precisarão ter seus componentes escritos usando controles móveis nativos.

Para dar um exemplo mais visual, vamos olhar para o mesmo componente escrito para Blazor WebAssembly, que usa um renderer compatível com padrões da Web, vs Mobile Blazor Bindings, que usa o renderizador baseado em padrões não web.

 

 

// WebAssembly Renderer

 

 

 

div

 

pCurrent count: @currentCount/p

 

button class=”btn btn-primary” @Click me/button

 

/div

 

 

 

@code {

 

private int currentCount = 0;

 

 

 

private void IncrementCount()

 

{

 

currentCount++;

 

}

 

}

 

 

 

// MobileBlazorBindings Renderer

 

 

 

StackLayout

 

Label FontSize=”30″ Text=”@($”Current count: {currentCount}”)” /

 

Button Text=”Click me” OnClick=”@IncrementCount” /

 

/StackLayout

 

 

 

@code {

 

private int currentCount = 0;

 

 

 

private void IncrementCount()

 

{

 

currentCount++;

 

}

 

}

 

É f&aacut