Ahí van los enlaces recopilados durante la semana pasada. Espero que os resulten interesantes. :-)
Por si te lo perdiste...
- Entender código imposible mediante troceado y refactorización
José María Aguilar - Mejoras en bloques try/catch de C# 6
José María Aguilar
.NET Core / .NET
- Introducing .NET Smart Components - AI-powered UI controls
Daniel Roth - Working with yield in C#: Enhancing Efficiency and Code Clarity
A. Yohan Malshika - Why Should We Avoid Using Await in a Loop in C#
Anaedobe Nneka - How to Resolve IOptions Instance Inside Program Class in C#
Georgi Georgiev - Difference Between await and Task.Wait in C#
Georgios Panagopoulos - .NET Developers Begging for Ecosystem Destruction
Aaron Stannard - NCronJob - Scheduling made easy
Steven Giesel - Conventional Message Routing in Wolverine
Jeremy D. Miller - Execute the SELECT WHERE NOT EXIST SQL Query Using LINQ
Karthikeyan N. S. - C# 12: Collection Expressions
Thomas Claudius Huber - General Performance Tip: Logging
David McCarter - Generate a Word document in ASP.NET
John Reilly - Building Interactive Blazor Apps with WebAssembly
Ed Charbeneau - How to Convert IAsyncEnumerable to List
Caleb Okechukwu - Benchmark a Method’s Performance on Different .NET Versions
Januarius Njoku
Publicado por José M. Aguilar a las 8:05 a. m.
Etiquetas: enlaces
Como sabéis, con ASP.NET Core 8 se ha incluido la posibilidad de que una página Blazor sea capaz de procesar directamente una petición HTTP, renderizando sus componentes y retornando el resultado HTML completo al lado cliente de forma estática. Es ya lo vimos hace algún tiempo cuando hablamos de Server-Side Rendering (SSR), una de las piezas clave para conseguir que Blazor sea un framework fullstack.
En la práctica, esta opción posibilita la implementación de sitios estáticos completos, como los que construiríamos con ASP.NET Core MVC, Razor Pages o cualquier otro tipo de tecnología de servidor, pero con la gran ventaja de que en este caso estaremos beneficiándonos del fantástico modelo de componentes Blazor, que es una gozada en términos de productividad y facilidad de uso, y sin perder la posibilidad de activar la interactividad de los componentes (su capacidad para reaccionar ante eventos del usuario), una vez que el HTML ha sido descargado en el navegador.
En aquél momento vimos que SSR no requiere una programación específica: los mismos componentes interactivos que luego podemos ejecutar en el lado cliente o servidor pueden ser renderizados mediante SSR de forma estática en el backend. Sin embargo, en algunos momentos nos podría resultar interesante saber si un componente está funcionando en modo estático (SSR) o interactivo (los tradicionales Blazor WebAssembly o Blazor Server).
Ahí van los enlaces recopilados durante la semana pasada. Espero que os resulten interesantes. :-)
Por si te lo perdiste...
- Constructores estáticos, inicializadores de módulos y startup hooks: tres formas de ejecutar código antes que Program.Main()
José María Aguilar - Inicialización de diccionarios en C# 6
José María Aguilar
.NET Core / .NET
- Measuring .NET Performance: Unleashing the Power of BenchmarkDotNet
Antão Almada - Fastest Way to Get the First N Characters of a String in C#
Januarius Njoku - Understanding System.Diagnostics DiagnosticSource and DiagnosticListener (Part 1)
Steve Gordon - How to Automatically Cast Between Types in C#
Nick Cosentino - Behind the implementation of .NET's PriorityQueue
Andrew Lock - C# 12: Primary Constructors
Thomas Claudius Huber - Mocking HttpClient requests for C# unit tests
Thomas Ardal - Get started with .NET 8 and AI using new quickstart tutorials
Jordan Matthiesen - Fastest Way to Generate a Random Boolean in C#
Matjaz Prtenjak - How to Use StringPool to Reduce String Allocations in C#
Osman Sokuoglu - Plugin Architecture in C# for Improved Software Design
Nick Cosentino - Why I Don't Use AutoMapper in .Net
Grant Riordan - LINQ Query Improvements in Marten 7
Jeremy D. Miller - Async Event Handlers in C#: What You Need to Know
Nick Cosentino - Comparing Performance of the switch and if-else Statements in C#
Michal Kaminski - Activator.CreateInstance vs Type.InvokeMember – A Clear Winner?
Nick Cosentino
Los que llevamos muchos años programando con ASP.NET/ASP.NET Core y todos los frameworks que han ido surgiendo en su ecosistema, estamos familiarizados con el concepto de "contexto HTTP".
Materializado en forma de objeto de tipo HttpContext
, el contexto HTTP es una de las piezas fundamentales de la infraestructura de ASP.NET Core, y nos permite acceder a información sobre la petición HTTP que se está procesando, como los encabezados, el cuerpo de la petición, las cookies, etc., así como base para la generación de la propia respuesta a través de su propiedad Response
. En muchos escenarios, se trata de un recurso imprescindible para procesar la petición de la forma adecuada, por lo que estamos acostumbrados a usarlo cuando es conveniente.
Sin embargo, cuando saltamos a Blazor, pronto nos llama la atención que HttpContext
no está disponible. Y si lo pensamos, esto tiene bastante sentido en los dos modos de renderización clásicos:
-
En Blazor WebAssembly, dado que el código .NET se ejecuta directamente en el cliente, no existen peticiones que procesar y, por tanto, no existe
HttpContext
. Se trata de una abstracción que sólo existe en el backend. -
En Blazor Server, aunque el código se está ejecutando en el servidor, tampoco tenemos disponible
HttpContext
porque realmente no existen peticiones: el lado cliente y servidor se comunican mediante un canal websockets implementado con SignalR, que es por donde viajan ascendentemente las acciones realizadas por el usuario y descendentemente las actualizaciones del DOM de la página.
Con la llegada de Blazor 8, ha tomado relevancia el nuevo modo de renderizado, llamado Server-Side Rendering (SSR) o renderización en el lado servidor, que ya vimos por aquí hace algún tiempo.
Como ya sabemos, el funcionamiento de Blazor SSR es similar al de otros frameworks de backend puros, como MVC o Razor Pages: el servidor recibe la petición, la procesa y genera una respuesta HTML que se envía al cliente. En este escenario, durante el proceso del componente Blazor sí existe un contexto HTTP.
Ahí van los enlaces recopilados durante la semana pasada. Espero que os resulten interesantes. :-)
Por si te lo perdiste...
- Requerir parámetros de la query string en ASP.NET Core
José María Aguilar - Rendimiento de nameof en C#
José María Aguilar
.NET Core / .NET
- Key derivation in .NET using HKDF
Anthony Simmon - An introduction to the heap data structure and .NET's priority queue
Andrew Lock - How To Use Polly In C#: Easily Handle Faults And Retries
Nick Cosentino - ConfigureAwaitOptions in .NET 8
Bart Wullems - Introduction to Brighter in .NET
Code Maze - Unveiling Spargine 8: A Comprehensive Guide to .NET 8 Integration and Exciting Feature Updates
David McCarter - Implicit Operators in C#: How To Simplify Type Conversions
Nick Cosentino - Optional parameters may appear in the middle of the parameter list
Gérald Barré - From SerilogTimings to SerilogTracing
Nicholas Blumhardt - Read a Text File Without Specifying the Full Path in C#
Aneta Muslic - Typesafety in xUnit with TheoryData<T>
Steven Giesel - Using parameters in BenchmarkDotNet
Bart Wullems - Extract Method Refactoring Technique in C# – What You Need To Know
Nick Cosentino - Stop Using string.ToLowerInvariant() to Compare Strings. InvariantCulture Comparisons are Slow
Darren Horrocks - Difference Between Abstraction and Encapsulation in C#
Almir Tihak - General Performance Tip: Hashing Data
David McCarter - R3 — A New Modern Reimplementation of Reactive Extensions for C#
Yoshifumi Kawai
En Blazor es posible acceder a valores de parámetros de la query string exclusivamente desde componentes de tipo página, es decir, aquellos definidos con la directiva @page
.
Para ello, bastaba con declarar una propiedad pública y decorarla con los atributos [Parameter]
y [SupplyParameterFromQuery]
. Por ejemplo, si desde una página quisiésemos obtener el valor del parámetro term
de la query string, podríamos hacerlo de la siguiente forma:
@page "/search"
<p>Searching term: @Term</p>
@code {
[Parameter]
[SupplyParameterFromQuery]
public string Term { get; set; }
}
Sin embargo, como sabéis, esto no funcionaba si intentábamos acceder así a estos parámetros desde componentes que no fueran páginas, es decir, que no fueran instanciados por el sistema de routing.
Ahí van los enlaces recopilados durante la semana pasada. Espero que os resulten interesantes. :-)
Por si te lo perdiste...
- Una forma más eficiente de comprobar si un texto es un JSON válido
José María Aguilar - El operador nameof de C# 6
José María Aguilar
.NET Core / .NET
- String Performance: Comparing Strings with Globalization
David McCarter - A C# LINQ one-liner to check if exactly one of a set of conditions is met
Raymond Chen - Testing exceptions
Mark Seemann - Parallel.ForEachAsync and Exceptions
Jeremy Clark - C# Tip: IFormattable interface, to define different string formats for the same object
Davide Bellone - Reflection in C#: 4 Simple But Powerful Code Examples
Nick Cosentino - Lock statement patterns
Steven Giesel - async await in C#: 3 Beginner Tips You Need to Know
Nick Cosentino - MoaidHathot/Dumpify: Adding
.Dump()
extension methods to Console Applications, similar to LinqPad's.
Moaid Hathot - Continue Processing with Parallel.ForEachAsync (even when exceptions are thrown)
Jeremy Clark - Mocking authorization tokens with WireMock.NET
Cezary Piątek - Activator.CreateInstance in C# – A Quick Rundown
Nick Cosentino