martes, 5 de mayo de 2020
Normalmente un componente Blazor declara parámetros para permitir que otros componentes o páginas que lo utilicen puedan pasarle la información que necesita para funcionar.
Por ejemplo, el siguiente código en el interior de un componente definiría un par de propiedades llamadas
Por ejemplo, el siguiente código en el interior de un componente definiría un par de propiedades llamadas
Text
y Repeat
, que utiliza para repetir un texto tantas veces como se le indique:@* File: Repeater.razor *@
@for (var i = 0; i < Repeat; i++)
{
<p>@Text</p>
}
@code {
[Parameter]
public string Text { get; set; }
[Parameter]
public int Repeat { get; set; }
}
De esta forma, podríamos utilizar el componente desde otros puntos de la aplicación suministrándole los valores necesarios en cada caso:<Repeater Text="Hola" Repeat="6" />
Sin embargo, alguna vez podría resultar interesante poder obtener todos los parámetros que se han enviado a un componente, pero sin necesidad de conocerlos previamente.Publicado por José M. Aguilar a las 8:05 a. m.
Hay
3 comentarios, ¡participa tú también!
Etiquetas: blazorserver, blazorwasm, trucos
lunes, 4 de mayo de 2020
El (relativamente desconocido) código de estado HTTP 402 (Payment required) se reservó para usos futuros hace más de veinte años, pensando que en algún momento se utilizaría para indicar al lado cliente que la operación solicitada requería "pasar por caja" antes de ser ejecutada.
Sin embargo, la idea nunca se desarrolló y, a falta de una especificación formal, no se generalizó su uso. Personalmente, jamás he implementado una API o servicio que retorne HTTP 402, pero hay algunos proveedores de servicios que sí lo hacen, aunque de forma arbitraria y no normalizada.
Esta era la píldora cultural del día, vamos con el tema que nos ocupa :)
Seguimos de encierro una semana más, aunque ya con la posibilidad de disfrutar de pequeños paseos (limitados en tiempo y distancia) o de hacer deporte en el exterior. Esto hace que el futuro se vea con algo más de optimismo, aunque espero que esta tímida apertura no provoque una vuelta atrás en los avances conseguidos hasta el momento.
Y mientras la cosa se aclara, podéis ir echando un vistazo a los enlaces recopilados durante la semana pasada que, como de costumbre, espero que os resulten interesantes. :-)
Sin embargo, la idea nunca se desarrolló y, a falta de una especificación formal, no se generalizó su uso. Personalmente, jamás he implementado una API o servicio que retorne HTTP 402, pero hay algunos proveedores de servicios que sí lo hacen, aunque de forma arbitraria y no normalizada.
Esta era la píldora cultural del día, vamos con el tema que nos ocupa :)
Seguimos de encierro una semana más, aunque ya con la posibilidad de disfrutar de pequeños paseos (limitados en tiempo y distancia) o de hacer deporte en el exterior. Esto hace que el futuro se vea con algo más de optimismo, aunque espero que esta tímida apertura no provoque una vuelta atrás en los avances conseguidos hasta el momento.
Y mientras la cosa se aclara, podéis ir echando un vistazo a los enlaces recopilados durante la semana pasada que, como de costumbre, espero que os resulten interesantes. :-)
Por si te lo perdiste...
- Limpiar la clase Startup de ASP.NET Core
José María Aguilar - Enumerables asíncronos en C# 8
José María Aguilar
.NET Core / .NET
- Cómo escribir información adicional de salida en nuestros tests de xUnit
Jorge Serrano - Web scraping de una página web y conversión a pdf con .NET Core 3.1
Jorge Serrano - Work flow of diagnosing memory performance issues – Part 2
Maoni Stephens - Introducing C# Source Generators
Phillip Carter - Did you know ? Easy and custom debugging with DebuggerDisplay and DebuggerTypeProxy attributes on Visual Studio
Anthony Giretti - Dotnet core 3.0 Self Contained Single Executable (and other build optimisations)
Darren Horrocks - The Dispose Pattern is Broken
Paulo Zemek - Demystifying Memory Profilers in C# .NET Part 2
Michael Shpilt - Exception Helper – Rethrown Exceptions
Andy Sterland - How to use CancellationTokens to cancel operations in the Azure SDK for .NET
Adrian Hall - Split a string into lines without any allocation
Gérald Barré - INotifyPropertyChanged with C# 9.0 Source Generators
Jerome Laban - Performance in .NET – Part 4
Ricardo Peres - Access to EXIF tags in JPEG files
Hans-Peter Kalb - C# 8.0 nullable references: inferred (non-)nullness
Ian Griffiths - Markdown .NET Core Library
Jason Gaylord
martes, 28 de abril de 2020
Hoy va un truquillo rápido sobre Blazor que puede resultar útil en muchos escenarios. Como probablemente sepáis, al igual que ocurre con otras tecnologías, Blazor codifica la salida HTML por motivos de seguridad, de forma que cualquier contenido con código de marcado será mostrado por defecto tal cual, sin interpretar las etiquetas.
Por ejemplo, considerad el siguiente código en un componente Blazor:
Por ejemplo, considerad el siguiente código en un componente Blazor:
<p>This text is encoded: @myHtml</p>
@code {
string myHtml = "Hello, <b>this is bold</b>";
}
El resultado que enviaremos al navegador es el siguiente:<p>This text is encoded: Hello, <b>this is bold</b></p>
Y, por tanto, nuestros usuarios podrán leer literalmente este párrafo:This text is encoded: Hello, <b>this is bold</b>
Normalmente no es eso lo que queremos mostrarles, ¿verdad?
lunes, 27 de abril de 2020
Aunque seguimos en el túnel, parece que tímidamente está apareciendo un poco de luz en la lejanía. Y mientras la cosa se ilumina del todo, quizás os entretengan un rato los enlaces recopilados durante la semana pasada, que, como de costumbre, espero que os resulten interesantes. :-)
Por si te lo perdiste...
- Switch expressions en C# 8
José María Aguilar - Confluencia de ramas en el pipeline de ASP.NET Core
José María Aguilar
.NET Core / .NET
- Como leer programáticamente contadores de rendimiento en .Net Core
Jorge Turrado - Announcing .NET 5.0 Preview 3
Richard Lander - Unit bias against collections
Mark Seemann - The Most Exciting Promise of .NET 5
Heather Downing - Enjoy Local Development with Tye, Docker, and .NET
Khalid Abuhakmeh - Building End-to-End Diagnostics and Tracing: Diagnostic Events
Jimmy Bogard - Nullable Reference Types: Migrating a Codebase – A Look at New Language Features in C# 8
Matthias Koch - Introducing Jasper as an In Process Command Bus for .Net
Jeremy D. Miller - C# 9 – Positional or Nominal Creation
Christian Nagel - Creating and Packaging a .NET Standard library
Sayed Hashimi - Verify User File Uploads With .NET
Khalid Abuhakmeh - Demystifying Memory Profilers in C# .NET Part 1: The Principles
Michael Shpilt - Referencing a Specific Assembly from a NuGet Package
Maarten Balliauw - Finalization Queue Tips
Mark Downie - .NET Core Tab Completion With Zsh
Khalid Abuhakmeh
martes, 21 de abril de 2020
Es lógico pensar que muchas de las aplicaciones que construyamos con Blazor, sobre todo en el mundo empresarial, necesitarán acceder a bases de datos para obtener o almacenar información.
En caso de utilizar Blazor WebAssembly, ese acceso encajará conceptualmente con lo que venimos haciendo desde hace años al construir aplicaciones SPA: desde el lado cliente simplemente llamaremos a una API o endpoint que actuará como pasarela, por lo que todo el código de acceso a datos se encontrará en el servidor. Aunque existen algunas iniciativas para posibilitar que EF Core funcione directamente en el navegador con algunos proveedores, ciertamente no será el escenario habitual.
Sin embargo, si utilizamos Blazor Server, tendremos la sensación inicial de que es todo más sencillo. El código de eventos bindeados a la interfaz se ejecuta en servidor, por lo que a priori sólo tendríamos que replicar lo que solemos hacer con servicios o controladores: solicitar una instancia del contexto de datos al inyector de dependencias, y utilizarla para lograr nuestros propósitos.
Pero no, la cosa es algo más complicada que eso. De hecho, los que ya estéis creando aplicaciones Blazor Server con EF Core seguro que os habéis topado en algún momento con un error como el siguiente:
¿Por qué ocurre esto?
En caso de utilizar Blazor WebAssembly, ese acceso encajará conceptualmente con lo que venimos haciendo desde hace años al construir aplicaciones SPA: desde el lado cliente simplemente llamaremos a una API o endpoint que actuará como pasarela, por lo que todo el código de acceso a datos se encontrará en el servidor. Aunque existen algunas iniciativas para posibilitar que EF Core funcione directamente en el navegador con algunos proveedores, ciertamente no será el escenario habitual.
Sin embargo, si utilizamos Blazor Server, tendremos la sensación inicial de que es todo más sencillo. El código de eventos bindeados a la interfaz se ejecuta en servidor, por lo que a priori sólo tendríamos que replicar lo que solemos hacer con servicios o controladores: solicitar una instancia del contexto de datos al inyector de dependencias, y utilizarla para lograr nuestros propósitos.
Pero no, la cosa es algo más complicada que eso. De hecho, los que ya estéis creando aplicaciones Blazor Server con EF Core seguro que os habéis topado en algún momento con un error como el siguiente:
InvalidOperationException: A second operation started on this context before a previous operation
completed. This is usually caused by different threads using the same instance of DbContext. For
more information on how to avoid threading issues with DbContext, see
https://go.microsoft.com/fwlink/?linkid=2097913.
Esta excepción se debe a que existen dos hilos de ejecución utilizando la misma instancia del contexto de datos al mismo tiempo, algo que Entity Framework no permite. Esto ocurrirá, por ejemplo, si tenéis en la misma página varios componentes que de forma concurrente intentan acceder a la base de datos al inicializarse.¿Por qué ocurre esto?
lunes, 20 de abril de 2020
Pues recién cumplidos los diez años desde que comencé a publicar enlaces de interés todas las semanas, vamos ahora a por la entrega número 400. Como siempre, espero que os resulten interesantes y os ayuden a llevar mejor estos días :)
Por si te lo perdiste...
- Novedades en la compilación de vistas en ASP.NET Core 3.0, ¡otra vez!
José María Aguilar - Ramificar el pipeline de ASP.NET Core con Map() y MapWhen()
José María Aguilar
.NET Core / .NET
- Work flow of diagnosing memory performance issues – Part 1
Maoni Stephens - Pretty Method Display in xUnit.net
Jason Roberts - Using .NET Core to provide Power Query for Excel on Mac
Oded Hanson - A Framework to DotNet Core Conversion Report
Mike Hadlow - C# 8.0 nullable references: non-nullable is the new default
Ian Griffiths - Serilog Logging Best Practices
Ben Foster - C# 8, A Year Late
Dave Brock - .NET JIT compiler is not type safe
Konrad Kokosa - A little riddle with AsyncLocal
Nelson Parente - 7 ways to improve code quality in C# using option type
Ahmed Fouad