Omarsoft For IT Solutions

.NET 6 is coming and, with it, some notable Blazor improvements. Dynamic components, hot reload, Blazor MAUI apps—the list goes on and on. Here are some of the main highlights.

.NET 6 is shaping up nicely ahead of its November release, but what’s in it for Blazor?

Here are a few of the standout changes coming in Blazor’s next significant release.

Dynamic Components

The standard way to build a Blazor app is to break the UI down into a number of smaller components which you can then compose together to build a larger section of the UI.

Greeting.razor

<p>Hello @Name</p>
    
@code {
	[Parameter]
	public string Name { get; set; }    
}

Index.razor

@page "/"

<Greeting Name="Jon"/>
<Greeting Name="Esme"/>

So in this case we’d see two Hello messages if we visited the application’s home page.

This is great for those occasions when you know ahead of time exactly which components you want to display.

But what about those times when you need to render varying components at runtime, based on data.

Take, for example, a customizable dashboard where your users could pick and choose which widgets they wanted displayed.

In this case it might be desirable to store those dashboard preferences/design as data, then read that data and dynamically render the relevant component(s).

Say we have a List of Dashboard components, stored as types:

List<Type> widgets = new List<Type>{ typeof(Counter), typeof(FetchData) }

We can loop over that list and render each component (according to its type):

@foreach(var widgetType in widgets){
    <DynamicComponent Type="@widgetType"/>
}

This would render the Counter and FetchData components.

But what if we need to pass extra parameters to the dynamic component? We can’t just pass them to the DynamicComponent when we declare it because we can’t know at compile-time which component is going to be rendered.

For this scenario we can pass a dictionary of parameters.

Extending our widget example, if we create a class or record to represent a widget:

public record Widget {
    public Type Type;    
    public IDictionary<string, object> Parameters;
}

Then store a list of them in our Blazor component, we can iterate over each one and pass the Parameters along to DynamicComponent.

@page "/"

@foreach (var widget in widgets)
{   
    <DynamicComponent Type="@widget.Type" Parameters="@widget.Parameters"/>
}

@code {
    private readonly List<Widget> widgets = new()
    {
        new Widget { Type = typeof(FetchData) },
        new Widget
        {
            Type = typeof(Greeting), 
            Parameters = new Dictionary<string, object>
            {
                ["Name"] = "Jon"
            }
        }
    };
}

This is equivalent to:

@page "/"

<FetchData />
<Greeting Name="Jon" />

Except now we can change the dashboard at runtime by adding/removing items to the List<Widget>.

Hot Reload

It’s hard to overstate the importance of a fast feedback loop when developing for the web.

So much of “modern” web development involves making small changes to HTML, CSS, UI logic and it’s hard to rapidly iterate your design when you find yourself waiting to see those changes spring to life in the browser.

Improving this feedback loop was a priority for .NET 6, and the preview releases have shown steady improvements with each release.

Ahead of Time Compilation (Blazor Wasm)

AOT directly compiles your .NET code to WebAssembly as part of the compilation process.

This is different from the standard way your Blazor Wasm apps run today, where your code is never compiled to WebAssembly, instead running on a .NET IL interpreter (which is itself implemented in WebAssembly).

This use of an interpreter means, in practice, your standard Blazor Wasm app will perform more slowly than it would on a normal .NET runtime (for example an MVC or Razor Pages app running on a server).

AOT addresses this performance issue by compiling your code to WebAssembly. For CPU-intensive tasks the performance improvement is significant (up to 5 times faster), but AOT compilation brings its own tradeoffs.

It requires an additional build tool to be installed, the actual compilation itself is quite slow (as of Preview 7) and AOT-compiled apps are larger (about 2x larger on average).

To use AOT you’ll need to install the latest .NET WebAssembly tools (watch out, the name of these tools changed between Preview 4 and Preview 7 of .NET 6. The new name is shown below).

dotnet workload install wasm-tools

The main tradeoff is that you’ll sacrifice load time for runtime performance, so the decision as to whether this makes sense will vary depending on the specific app you’re building.

Blazor Query String Component Parameters

You could do this previously but you had to lean on Microsoft.AspNetCore.WebUtilities and write your own code to handle it.

Now it’s much simpler as you can simply decorate your parameters with the new SupplyParameterFromQuery attribute:

[Parameter]
[SupplyParameterFromQuery]
public string Filter { get; set; }

With this, if you append ?filter=x to the URL for your Blazor page, the corresponding parameter (Filter) will be populate with the value from query string.

Note there’s currently a debate ongoing about the name of the attribute, so it may change in a future release but the functionality will remain the same.

Required Parameters

[EditorRequired]
[Parameter]
public string Name { get; set; }

If you attempt to use the component without specifying required parameters, you’ll get an error at design time (in your IDE and/or when the app is compiled).

Worth noting it isn’t enforced at runtime so doesn’t guarantee that your parameters values will not be null.

Modify HTML Head From Blazor

You can easily change the page title and add meta tags for SEO without resorting to JS interop to get the job done.

For this, .NET 6 introduces two new components: PageTitle and HeadContent.

You can change the page title using PageTitle.

<PageTitle>@title</PageTitle>

@code {
	private string title = "Dynamic title!"
}

And add anything else you like to the HTML <head> via HeadContent.

<HeadContent>
	<meta name="description" content="@description">
</HeadContent>

@code {
	private string description = "Comprehensive dynamic description"
}

Error Boundaries

With the current/previous release of Blazor, any exception thrown in any component would generally result in your entire application failing, often requiring a restart of the entire app.

With .NET 6 you can contain the chaos and wrap any part of your application in an error boundary.

<h1>Super Fancy Application</h1>
<div>
    <ErrorBoundary>
    	<Counter />
    </ErrorBoundary>
</div>

Now if Counter throws an exception, an error will be displayed where the ErrorBoundary is declared, leaving the rest of the UI unaffected.

By default error boundaries render an empty div with a blazor-error-boundary CSS class when an exception occurs. However, you can take more control of that error if you wish:

<h1>Super Fancy Application</h1>
<div>
    <ErrorBoundary>
        <ChildContent>
            <Counter />
        </ChildContent>
    	<ErrorContent>
        	<p class="bad-error">
                Oh dear, something went horribily, horribly wrong whilst attempting to count...
            </p>
        </ErrorContent>
    </ErrorBoundary>
</div>