En mi anterior artículo presenté Blazor, la nueva tecnología de Microsoft para crear aplicaciones Web basadas en servidor o en navegador usando .NET y C#.
Ese artículo proporcionaba una visión general de Blazor, cómo se relaciona con .NET y con los navegadores, qué es WebAssembly y cuáles son las posibilidades alucinantes que nos facilita esta tecnología.
En el artículo de hoy voy a profundizar un poco más con otras 7 preguntas y sus respuestas de modo que puedas conocer mejor cómo funciona, qué implica en cuanto a conocimientos y aprendizaje y que veas si te puede encajar la tecnología o no. Seguiré numerando las preguntas desde donde lo dejé y así tendrás una visión mejor.
¡Vamos allá!
8.- Hace algún tiempo oí hablar de Razor Components... ¿es lo mismo que Blazor, o se trata de algo distinto?
Bueno, aquí es que hubo un poco de lío al principio 😆
En enero de 2019, con la llegada de la preview 2 de .NET Core 3.0, se anunció la inclusión de Razor Components, que materializaba la capacidad de alojar componentes Blazor en el lado servidor. Es decir, antes de tomar su nombre definitivo, Blazor Server se llamó Razor Components durante algún tiempo.
Meses más tarde, ya en abril del mismo año, decidieron dar marcha atrás y renombraron definitivamente la tecnología como Blazor Server al lanzar la preview 4, porque pensaron que era bastante confuso, dado que Razor Components era una denominación que también era utilizada para referirse a los componentes de Blazor, los building blocks de las aplicaciones Blazor que se implementan en archivos .razor.
Hoy en día, la denominación "Razor Component" ha quedado exclusivamente para esta segunda acepción. Es decir, los componentes Blazor se implementan en archivos de Razor Components (archivos .razor), aunque en realidad creo que acabaremos llamándoles "Componentes Blazor" a secas la mayoría de las veces.
9.- ¿Y tiene esto algo que ver con Razor Pages? ¿O con Razor?
Un aire de familia sí que tienen, aunque en realidad se trata de cosas distintas.
Aunque coincida en parte el nombre con Razor Components, Razor Pages es una tecnología de servidor pura, construida sobre ASP.NET Core, y lanzada hace ya unos años, al abrigo de ASP.NET Core 2.0, como una actualización y puesta al día de lo que antes habíamos conocido como ASP.NET Web Pages.
El objetivo de este pequeño framework era permitir a los desarrolladores crear aplicaciones web adoptando un enfoque "por página", más simple y directo en muchos escenarios que la alternativa MVC. Es decir, con esta tecnología podemos hacer que una petición sea procesada directamente por una página, al estilo de cómo se hacen en otros frameworks y lenguajes de scripting para la web, en lugar de tener que crear controladores y vistas.
Por otro lado, Razor es la sintaxis que permite mezclar código de marcado (HTML) con C# de una forma bastante clara y productiva, y es precisamente el nexo de unión entre estas tecnologías: Blazor Componentes, Razor Pages e incluso las vistas MVC utilizan la sintaxis Razor, aunque cada una de ellas introduce algunas características propias que es necesario conocer.
10.- ¿Cómo se estructuran las aplicaciones en Blazor?
La forma de estructurar una aplicación Blazor se parece mucho a otros frameworks SPA. Muy a vista de pájaro, consiste en un Razor Component raíz, que normalmente aloja el sistema de routing. Éste se encargará de analizar los cambios en las rutas del navegador para mostrar las páginas de la aplicación.
Las páginas, que también se implementan como Razor Components, pueden utilizar dentro, a su vez, otros componentes, que pueden estar compuestos a su vez por otros componentes, y así hasta el infinito. Lo único que hace diferente a una página de un componente es que ésta incluye la directiva @page para indicar al sistema de routing cómo puede ser localizada (algo bastante similar a como lo hacemos al desarrollar con Razor Pages en MVC).
Por tanto, para crear la interfaz de una aplicación Blazor, lo único que tendremos que hacer es implementar Componentes Razor. Aparte, claro está, tendremos que implementar otro tipo de clases y estructuras habituales: servicios de aplicación, acceso a datos, lógica de negocio, etc., que pueden ser utilizadas desde los archivos .razor gracias a la inyección de dependencias.
11.- ¿Qué pinta tiene por dentro un Componente Razor?
Pues si has utilizado alguna vez Razor Pages o MVC, la pinta es muy parecida a lo que ya conoces para el desarrollo de páginas o vistas.
Por ejemplo, el siguiente código podría ser un Componente Razor que actúa como página y que en su interior utiliza otro componente:
@* File: Pages/Index.razor *@
@page "/"
<h1>Hello, world!</h1>
Welcome to your new app.
<hr />
<Multiplication Number="5"></Multiplication>
Fíjate en que con la directiva @page indicamos al sistema de routing mediante qué ruta debe ser accesible el contenido. Ya en su interior, podemos observar que utilizamos un Componente Razor llamado <Multiplication>, que mostrará tablas de multiplicar. Puedes ver el funcionamiento en la animación anterior.
A continuación, veamos el código del componente <Multiplication>, definido en el archivo Multiplication.razor de la siguiente forma:
@* File: Pages/Multiplication.razor *@
<h3>Multiplication</h3>
<div>
<label>Select a number:</label>
<select @bind="Number">
@for (var i = 1; i < 10; i++)
{
<option>@i</option>
}
</select>
</div>
<div>
<h5>Multiplication table of @Number,
using font-size @(FontSize)pt:</h5>
<ul style="font-size: @(FontSize)pt">
@for (var i = 1; i <= 10; i++)
{
<li>@Number * @i = @(Number * i)</li>
}
</ul>
<button @onclick="ZoomIn">Zoom in</button>
<button @onclick="ZoomOut">Zoom out</button>
</div>
@code {
[Parameter]
public int Number { get; set; }
int FontSize { get; set; } = 10;
void ZoomIn() => FontSize++;
void ZoomOut() => FontSize--;
}
En este componente destacan varios aspectos:
- El uso de sintaxis Razor, esa mezcla de HTML y C# que encontramos a lo largo del contenido: expresiones de salida tipo
@var o @(var) para mostrar valores de variables, o incluso los clásicos bucles @for para mostrar listas o colecciones.
- La existencia del bloque
@code para definir miembros e implementar comportamientos en C#, que podría asimilarse a un típico view-model en otros frameworks MVVM.
- El uso de la directiva
@bind para bindear el valor actual del desplegable a la propiedad Number, que además actúa como parámetro para que las páginas o componentes que lo utilicen puedan establecerlo (nosotros lo habíamos hecho con el valor "1" desde la página).
- Podemos ver también el uso de
@onclick para asociar eventos "click" del DOM a handlers escritos en C# en la sección @code.
12.- ¿Los componentes que desarrolle para Blazor Server podrán funcionar luego en Blazor WebAssembly y viceversa?
El modelo de programación es el mismo en ambos tipos de hosting. Es decir, en principio, un Razor Component escrito sobre Blazor Server podría funcionar sin cambiar ni una sola línea de código en Blazor WebAssembly y viceversa.
Vuelve un momento al código que te mostraba en el punto anterior y analízalo desde el punto de vista de ambos modelos de hosting. Verás que no hay nada que lo ate especialmente al servidor o al cliente:
- Si lo ejecutamos en Blazor Server, el evento "change" del desplegable será enviado al servidor por el canal SignalR. En éste, se actualizará el valor de la propiedad
Number y se detectarán los cambios en el DOM que este cambio produce, enviándose de vuelta al cliente las porciones de HTML modificadas. Lo mismo ocurre con los eventos "click": serán enviados al servidor, procesados allí, y los cambios en el DOM enviados de vuelta al cliente.
- Si lo ejecutamos en Blazor WebAssembly, el evento "change" será procesado directamente desde el código .NET presente en el navegador.
En efecto, es el mismo código ejecutándose en dos escenarios totalmente distintos.
Sin embargo, la realidad es algo más compleja y hace que debamos tener en cuenta dónde se ejecutan los componentes para implementarlos de forma correcta.
Por ejemplo, imagina que en el handler de un evento click necesitamos acceder a recursos del servidor, como su sistema de archivos, una base de datos o cualquier otra cosa. Esto podremos hacerlo sin problema al hostear el componente en Blazor Server, puesto que esta ejecución se llevará a cabo precisamente en el servidor. Sin embargo, si el mismo código lo llevamos a Blazor WebAssembly, fallará estrepitosamente porque el código se ejecutará en el navegador.
¿Y cómo solucionamos estos escenarios? Pues es el momento en el que la inyección de dependencias llega a nuestro rescate :wink:
La forma correcta de implementar un requisito de ese tipo sería creando una abstracción que puedas implementar de forma personalizada en cada tipo de aplicación. Por ejemplo, si necesitamos manipular un archivo del servidor, podríamos crear una interfaz IServerFileAccessor y luego implementarla de forma diferente en cada host:
- En Blazor Server, la implementación simplemente accedería al archivo local para manipular el archivo de forma directa.
- En Blazor WebAssembly, la implementación podría usar una llamada HTTP para manipular el archivo a través de un endpoint HTTP publicado en el servidor.
De esta forma, el código de nuestro componente seguiría siendo el mismo y solo cambiaría la implementación de la interfaz, ya en función del hosting utilizado:
@inject IServerFileAccesor FileAccessor
<button @onclick="DoSomethingClick">
...
@code
{
async Task DoSomethingClick()
{ // Este código es el mismo para
await FileAccesor.DoSomethingAsync(); // Razor Server y Razor WebAssembly
}
}
Si conoces Xamarin Forms esto podría resultarte familiar, porque es lo mismo que estás haciendo cada vez que implementas servicios o custom renderers nativos que luego utilizas desde tu proyecto compartido.
13.- ¿Necesito herramientas especiales para programar con Blazor?
En absoluto. Puedes programar aplicaciones Blazor desde Windows, Mac o Linux, porque se trata de una tecnología basada en .NET Core y, por tanto, cross-platform. También puedes utilizar tu editor o entorno de desarrollo favorito (Visual Studio o cualquier otro).
Desde Visual Studio, como es habitual, tendremos bastantes ayudas a la hora de crear proyectos de este tipo, porque ya viene equipado de serie con plantillas, como también disfrutaremos de intellisense, depuración integrada y todas las ayudas a las que nos tiene acostumbrados.
Pero si preferimos otras opciones, somos libres de hacerlo :smile: Por ejemplo, podríamos crear un proyecto Blazor desde línea de comandos sin problema y, a partir de ahí, abrir el proyecto con Visual Studio Code sin demasiado esfuerzo:
C:\Test>dotnet new | find "blazor"
Blazor Server App blazorserver [C#] Web/Blazor
Blazor WebAssembly App blazorwasm [C#] Web/Blazor/WebAssembly
C:\Test>dotnet new blazorserver
The template "Blazor Server App" was created successfully.
This template contains technologies from parties other than Microsoft, see https://aka.ms/aspnetcore/3.1-third-party-notices for details.
Processing post-creation actions...
Running 'dotnet restore' on C:\Test\Test.csproj...
Restauración realizada en 85,39 ms para C:\Test\Test.csproj.
Restore succeeded.
C:\Test>code .
C:\Test>_
14.- Como desarrollador .NET, ¿me valen mis conocimientos actuales?
Por supuesto, y la idea de fondo de Blazor es precisamente esa, que desarrolladores con experiencia en C# y .NET puedan dar el salto a la Web sin demasiados problemas porque aprovechan al máximo sus conocimientos:
- Aprovecharás a tope tus conocimientos de C#, pues lo utilizarás para implementar la lógica de presentación en páginas y componentes de tus aplicaciones.
- Si ya conoces ASP.NET Core, te sentirás cómodo con Blazor Server, pues este tipo de hosting es, al fin y al cabo, una aplicación ASP.NET Core a la que se insertan algunos servicios y endpoints especiales. Toda la infraestructura (inyección de dependencias, logging, settings, etc.) es la misma. Con Blazor WebAssembly podrás aprovechar todos esos conocimientos para implementar backends de tus componentes de presentación.
- Si has trabajado con Razor en ASP.NET MVC, ASP.NET Web Pages, ASP.NET Core MVC o ASP.NET Razor Pages, podrás aprovechar estos conocimientos y simplemente aprender las diferencias existentes entre la anterior sintaxis y la usada en los Razor Components.
- Si conoces Web Forms, el modelo de programación de Blazor Server te resultará familiar y podrás adaptarte con relativa facilidad. Pero ojo, si lo único que has hecho en el mundo Web es de la mano de Web Forms, quizás te cueste más acostumbrarte a trabajar cerca de la web real (HTML, CSS) que a Blazor.
- Si llevas tiempo con .NET, podrás aprovechar conocimientos y reutilizar componentes para implementar las aplicaciones Blazor usando bibliotecas y código que ya conoces o puedes reutilizar. Incluso en el caso de Blazor WebAssembly, lo que llevamos al browser son ensamblados .NET Standard, por lo que probablemente puedas aprovechar cosas.
- Si has trabajado con otros frameworks SPA no tendrás demasiado problema para "mapear" tus conocimientos a Blazor porque los conceptos son muy similares, acelerando así tu proceso de aprendizaje.
- Conocer JavaScript te vendrá de perlas para implementar escenarios interop y reutilizar componentes o bibliotecas existentes.
- Si has trabajado con Visual Studio podrás utilizar tus habilidades y herramientas habituales para crear, desarrollar y depurar aplicaciones Blazor.
En resumen, si eres un desarrollador .NET con cierta experiencia en el mundo Web moderno, el salto a Blazor te resultará bastante cómodo. Obviamente habrá que aprender las peculiaridades de este framework, pero el esfuerzo requerido es relativamente moderado, y diría que incluso mucho más leve que el requerido si pretendemos dar un salto desde cero a otros como Angular.
Fecha de publicación: