Ahí van los enlaces recopilados durante la semana pasada. Espero que os resulten interesantes. :-)

.NET / .NET Core

• C# Debug vs. Release Builds and Debugging in Visual Studio – from Novice to Expert in One Blog Article
  Ben Hall
• First steps with nullable reference types
  Jon Skeet
• Adding Resilience and Transient Fault handling to your .NET Core HttpClient with Polly
  Scott Hanselman
• Don’t Use Enumerables as Numbers
  Peter Vogel
• LINQ Part 4: A Deep Dive Into a Queryable Extension Method
  Eric Lynch
• Saber qué versiones de .NET Core y de SDK .NET Core tenemos instaladas
  Jorge Serrano
• Inferred tuple names in C# 7.1
  gunnar Peipman
• Setting up .NET Core Configuration Providers
  Randy Patterson

Hace unos días hablábamos de las, a veces desconocidas, redirecciones HTTP 303, 307 y 308, y comentábamos el por qué de su existencia y los escenarios en los que debían ser utilizadas si queremos seguir de forma más estricta el protocolo HTTP a la hora de implementar APIs o aplicaciones.

Pues bien, al hilo de esto, en este post veremos muy rápidamente cómo podemos implementar estas redirecciones en ASP.NET Core MVC que, como veréis, nos lo pone bastante fácil.

Ahí van los enlaces recopilados durante la semana pasada. Espero que os resulten interesantes. :-)

.NET / .NET Core

• Help us plan the future of .NET!
  Aditi Dugar
• Performance Improvements in .NET Core 2.1
  Stephen Toub
• 7 things you didn’t know about .NET code
  Liviu Costea
• Sharing is Caring: Using Memory Mapped Files in .NET
  Tom Fisher
• C# Array: Definition, Examples, Best Practices, and Pitfalls
  Justin Boyer

Va un truquillo muy rápido que, aparte de al que os habla, quizás a alguno más os provoque un momento “ahh, pues claro, cómo no se me había ocurrido antes” ;)

Y es que el problema con las costumbres es que son difíciles de quitar; por ejemplo, probablemente muchos estamos acostumbrados a obtener el nombre de los miembros de un enum de la siguiente forma:

public enum Color { Red, Green, Blue }
static void Main(string[] args)
{
    Console.WriteLine(Color.Red.ToString()); 
    // Output: Red
}

A priori es correcto: llevamos años haciéndolo así y no nos ha ido mal del todo. Bueno, o sí, pero probablemente no por este motivo ;)

Ahí van los enlaces recopilados durante la semana pasada. Espero que os resulten interesantes. :-)

.NET / .NET Core

• Announcing .NET Core 2.1 Preview 2
  Rich Lander
• C# 7.X and Beyond – A sneak peek at the future of C#
  Andrea Angella
• Cross-runtime .NET disassembly with BenchmarkDotNet
  Andrey Akinshin
• Performance traps of ref locals and ref returns in C#
  Sergey Teplyakov
• Switching between .NET Core SDK Versions
  Mark Heath
• Mimic Web Forms LinkButton Behavior in ASP.NET Core
  Scott Addie
• How we doubled Mono’s Float Speed
  Miguel de Icaza
• Searching docs using a .NET Core global tool
  Shayne Boyer
• Getting the .NET Core Runtime Version in a Running Application
  Rick Strahl
• Deconstructing KeyValuePair
  Ian Griffiths

Cuando desarrollamos una aplicación ASP.NET Core MVC, es muy frecuente encontrar que nuestras vistas definen secciones de contenido usando la directiva @section que más adelante se incluyen en el Layout para formar parte de la información enviada al lado cliente.

Sin embargo, ya sabemos que no es posible utilizar secciones en vistas parciales o cualquier otro tipo de componentes, lo cual complica algunos escenarios.

Por ejemplo, es relativamente frecuente que en el lado servidor generemos código HTML utilizando algún mecanismo de reutilización de marcado, como vistas parciales, templated helpers, tag helpers, etc., y que éste requiera recursos extra como scripts o CSS que obligatoriamente deberíamos incluir en las vistas principales donde se utilicen.

Más en el terreno práctico, imaginad que creamos una vista parcial que requiere que las páginas donde vayamos a usarla incluyan una referencia a un archivo de scripts y un bloque de inicialización como el siguiente:

@* Partial view: _MyComponent.cshtml *@
<div class="my-component">
    <!-- UI goes here -->
</div>

<!-- And now, add dependencies and initialization code -->
<script src="path/to/my-component.js" ></script>
<link rel="stylesheet" href="path/to/my-component.css" ></script>
<script>
   // Initialization code goes here
    $(".my-component").setup();
</script>

Aquí es donde comienzan los problemas. Si lo enfocamos como hemos mostrado anteriormente y resulta que en una misma página podemos tener más de una instancia de dicha vista parcial, estaremos incluyendo en la página las referencias y código de inicialización más de una vez, lo cual podría traernos bastantes dolores de cabeza:

<html>
    <body>
        ...
        <!-- My Component, instance #1 -->
        @Html.Partial("_MyComponent.cshtml")
        ...
        <!-- My Component, instance #2 -->
        @Html.Partial("_MyComponent.cshtml")
        ...
    </body>
</html>

Además de problemas de rendimiento y mal funcionamiento de la aplicación, también podría ocurrir que al insertar la parcial en la página, los scripts quizás aparecerían antes de referenciar los componentes o frameworks utilizados, pues normalmente esto suele hacerse al cerrarse el <body>.

Por ejemplo, en el código anterior nuestro componente utiliza JQuery, por lo que necesitamos que este framework se cargue antes de que nuestro código aparezca en la página, cosa que no siempre podremos asegurar. Así, el código enviado a la página podría ser el siguiente:

<html>
    <body>
        ...
        <!-- My Component, instance #1 -->
        <div class="my-component">
            <!-- UI goes here -->
        </div>
        <script src="path/to/my-component.js" ></script>
        <link rel="stylesheet" href="path/to/my-component.css" ></script>
        <script>
        // Initialization code goes here
            $(".my-component").setup();
        </script>        
        ...

        <!-- My Component, instance #2 -->
        <div class="my-component">
            <!-- UI goes here -->
        </div>
        <script src="path/to/my-component.js" ></script>
        <link rel="stylesheet" href="path/to/my-component.css" ></script>
        <script>
        // Initialization code goes here
            $(".my-component").setup();
        </script>        
        ...
        <script src="/scripts/jquery.min.js"></script>
    </body>
</html>

Obviamente, esto provocaría un error en la página.

En este post vamos a ver un posible enfoque para solucionar este escenario. La idea es bastante sencilla, pues simplemente vamos a hacer posible que cada vista parcial o componente pueda registrar código HTML que luego sea renderizado en un lugar específico de la página. El objetivo sería algo similar a lo que conseguimos con la definición de secciones @section y @RenderSection(), pero aplicable a cualquier tipo de vista parcial.