1. Partial Class Support for Razor Components

It can now generate razor components in the form of partial classes. It is now possible to write code for a Razor component using a code-behind file declared a partial class. Instead of defining all of the component’s code in a single file.

The Blazor framework includes Razor components. Blazor is a single-page application development framework that allows you to write the full application in C# and run it in the browser. To accomplish this, a new DOT NET runtime that supports WebAssembly is required. Blazor started as an experimental framework. A server-side paradigm was introduced as part of its evolution.

The C# code executes on the webserver, and a SignalR connection is utilized to make real-time updates to the application in the browser. This concept was formerly known as Razor Components and was formally implemented as part of DOT NET Core 3.0 in Preview 2. The development approach was renamed Server-side Blazor in Preview 4. Instead of referring to a development framework, the name Razor Component refers to a single building element within the Blazor framework.

Within Blazor, Razor components can take on several tasks. A Razor Page will replace a partial, a view component, or a custom tag helper (or an MVC view). A Razor Pages partial, view component, or tag helper, for example, can be represented by these. It can also use them to represent a layout. It can also use them to represent an entire page.

Razor components are stored in files that end with Razor. They can also be produced in.cshtml files, although we believe this increases the possibility of confusion. The .razor file combines HTML and C#, which is integrated into the HTML using the well-known Razor syntax. It is enabled primarily to help with backward compatibility with previous previews.

2. Pass Parameters to Top-Level Components

When the initial render occurs, Blazor Server apps can now provide parameters to top-level components. Previously, only RenderMode.It could use static to pass arguments to an important element’s however, both RenderMode.Server and RenderModel. ServerPrerendered is now supported as of this release. If a specific parameter value is taken into account, it is possible to serialize it as JSON and integrate it into the primary response.

You can use some form of this code in the release version of Blazor to launch your components from an MVC View, a Razor Page, or a View Component:

@(await Html.RenderComponentAsync(RenderMode.ServerPrerendered))

RenderComponentAsync accepts three RenderMode arguments: ServerPrerendered, Server, and Static. If you pick the Static option, you can only supply a parameter to the component via the RenderComponentAsync method. This code, for example, sends the View’s Model property to the component via a cust:

@(await Html.RenderComponentAsync(RenderMode.Static, new { cust = Model }))

Unfortunately, using the Static option causes your component to cease firing events. It signifies that your component cannot be interactive (your buttons stop firing click events, for example). Static components are not an option for any real-world application. In many cases, we want an interactive component that interfaces with my server-side application by taking data from the host View or Razor Page.

3. Support for Shared Queues in HttpSysServer

In addition to the current behavior of HttpSysServer creating anonymous request queues, the most recent version includes the option to build or attach to a regular named HTTP.sys request queue. As a result, there may be circumstances in which the HTTP.Sys controller process with the line is independent of the listener process. Finally, it aids in the preservation of existing connections and enqueued requests between listener process restarts.

4. Breaking Alterations for SameSite Cookies

This release contains a substantial modification to the behavior of SameSite cookies in ASP DOT NET Core. It adheres to the most current browser-supported standards. It may find more information on the modifications and their impact on existing apps here.

SameSite is an HTTP cookie addition introduced in 2016 to reduce cross-site request forgery (CSRF). The initial intention was to add a new SameSite value to cookies to activate an opt-in functionality. There were two options: Lax and Strict. Setting the value to Lax indicates that the cookie should be transmitted when navigating within the same site or navigation from other sites to your site. A Strict value restricted the cookie to requests that came from the same site only.

There were no limits on how the cookie flowed in requests if the property was not set at all. It can use cookies for correlation and CSRF prevention in OpenIdConnect authentication operations (e.g., login, logout) and other features that send POST requests from an external site to the site requesting the operation. To ensure that these cookies are sent during their specialized request flows, these organizations would need to opt-out of SameSite by not setting the property at all.

The DOT NET Core 3.1 Preview 1 release includes several new ASP DOT NET Core features. Contact a reliable ASP DOT NET development Company like us to take advantage of this latest ASP DOT NET web development functionality.