The recent launch of Angular version 16 introduces exciting updates and improvements to the development experience, as well as better application performance and stability.

1. Angular Signals

Angular Signals is a library that enables the definition of reactive values and the establishment of dependencies between them. Here’s a simple example of how to utilize Angular Signals within an Angular application:

@Component ({
   selector: 'my-app',
   standalone: true,
   template: `
{{ fullName() }} <button (click)="setName('John')">Click</button>
`,
})
export class App {
   firstName = signal('Jane');
   lastName = signal('Doe');
   fullName = computed(() => `${this.firstName()} ${this.lastName()}`);
   constructor() {
       effect(() => console.log('Name changed:', this.fullName()));
   }
   setName(newName: string) {
       this.firstName.set(newName);
   }
}

The above code snippet creates a computed value called fullName, which relies on the signals firstName and lastName. Additionally, it defines an effect, a callback function that runs whenever the value of the signals it reads changes.

In this case, the fullName value depends on firstName and lastName, so changing either of them triggers the effect. When the value of firstName is set to John, the browser logs the following message to the console:

 Name changed: John Doe.

2. Standalone Ng New Collection

Starting from Angular v16, you can create new standalone projects right from the beginning! To try out the developer preview of the standalone schematics, ensure that you have Angular CLI v16 installed and run the following command:

ng new --standalone

By doing this, you will obtain a simpler project structure without any NgModules. Furthermore, all the generators in the project will produce standalone directives, components, and pipes!

3. Automatic Route Params Mapping

Consider a routing configuration as follows:

export const routes: Routes = [{
   path: 'search:/id',
   component: SearchComponent,
   resolve: {
       searchDetails: searchResolverFn
   }
}];

Before Angular 16, you needed to inject the ActivatedRoute service to retrieve URL parameters, query parameters, or associated data for a particular URL.

Here's an example of how you had to do it:

@Component({
   ...
})
export class SearchComponent {
   readonly #activatedRoute = inject(ActivatedRoute);
   readonly id$ = this.#activatedRoute.paramMap(map(params => params.get('id')));
   readonly data$ = this.#activatedRoute.data.map(({
       searchDetails
   }) => searchDetails);
}

With Angular 16, you no longer need to inject the ActivatedRoute service to retrieve various route parameters because you can bind them directly to component inputs.

To activate this functionality in an application that uses the module system, set the corresponding value in the RouterModule options:

RouterModule.forRoot(routes, {
   bindComponentInputs: true
})

For a standalone application, you need to call a function instead:

provideRoutes(routes, withComponentInputBinding());

Once you activate this functionality, the component becomes much simpler:

@Component({
   ...
})
export class SearchComponent {
   @Input() id!: string;
   @Input() searchDetails!: SearchDetails;
}

4. Required Input

A highly anticipated feature for the Angular community is the ability to mark certain inputs as required. Until now, you had to use various workarounds to achieve this, like raising an error in the NgOnInit lifecycle if the variable was not defined or modifying the component's selector to include the mandatory inputs.

However, both of these solutions had their advantages and disadvantages. Starting from version 16, making an input required is as simple as providing a configuration object in the metadata of the input annotation:

@Input({
   required: true
}) name!: string;

5. Vite as Dev Server

Angular 14 introduced a new JavaScript bundler called EsBuild, which significantly improved build times by approximately 40%. However, you could only realize this performance gain during the build phase and not during development with the dev server.

In the upcoming release of Angular, the Vite build tool enables the use of EsBuild during development as well.

To activate this feature, update the builder configuration in the angular.json file as follows:

"architect": {
   "build": {
       "builder": "@angular-devkit/build-angular:browser-esbuild",
       "options": {
           ...
       }
   }

Please note that this functionality is still experimental.

Enhancing Development Experience and Performance

Angular version 16 brings exciting updates like Angular Signals for managing data, standalone project creation, automatic route params mapping, required inputs, and integration of Vite for improved development. These enhancements improve the development experience and increase application performance.

.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>