The First Browser War

Newer versions were released rapidly, and browsers started to add new features such as <blink> and <marquee> elements. This was the beginning of the first browser war, giving people (especially designers) headaches because some developers were building pages with blinking marquee controls . But developers were also getting sore heads because of incompatibilities between browsers. The first browser war was about having more HTML capabilities than the competition.

But all of this is now behind us with the introduction of HTML5 and modern browsers like Google Chrome, Microsoft Edge, Firefox, Safari, and Opera. HTML5 not only defines a series of standard HTML elements but also rules on how these should render, making it a lot easier to build a website that looks the same in all modern browsers. Then, in 1995, Brendan Eich wrote a little programming language known as ECMAScript (initially called LiveScript) in ten days (What!?). It was quickly dubbed JavaScript because its syntax was very similar to Java. I will be using the name JavaScript here because that is what most people call it.

JavaScript and Java are not related. Java and JavaScript have as much in common as ham and hamster (I don’t know who formulated this first, but I love this phrasing).

Little did Mr. Eich know how this language would impact the modern Web and even desktop application development. In 1995, Jesse James Garrett wrote a white paper called Ajax (Asynchronous JavaScript and XML), describing a set of technologies where JavaScript is used to load data from the server and that data is used to update the browser’s HTML. This avoids full page reloads and allows for client-side web applications, which are applications written in JavaScript that run completely in the browser. One of the first companies to apply Ajax was Microsoft when they built Outlook Web Access (OWA). OWA is a web application almost identical to the Outlook desktop application proving the power of Ajax. Soon other Ajax applications started to appear, with Google Maps stuck in my memory as one of the other keystone applications. Google Maps would download maps asynchronously and with some simple mouse interactions allowed you to zoom and pan the map. Before Google Maps, the server would do the map rendering and a browser displayed the map like any other image by downloading a bitmap from a server.

Building an Ajax website was a major undertaking that only big companies like Microsoft and Google could afford. This soon changed with the introduction of JavaScript libraries like jQuery and knockout.js (knockout was also written by Steve Sanderson, the author of Blazor!). Today, we build rich web apps with Angular, React, and Vue.js. All of them are using JavaScript or higher-level languages like TypeScript which gets transpiled into JavaScript.

Transpiling will take one language and convert it into another language. This is very popular with TypeScript which gives you a modern high-level typed language. You need JavaScript to run it in a browser, so TypeScript gets “transpiled” into JavaScript.

The Second Browser War

This brings us back to JavaScript and the second browser war. JavaScript performance is paramount in modern browsers. Chrome, Edge, Firefox, Safari, and Opera are all competing with one another, trying to convince users that their browser is the fastest with cool-sounding names for their JavaScript engine like V8 and Chakra. These engines use the latest optimization tricks like Just-In-Time (JIT) compilation where JavaScript gets converted into native code as illustrated in Figure 1-1.

This process takes a lot of effort because JavaScript needs to be downloaded into the browser, where it gets parsed, then compiled into bytecode, and then Just-In-Time converted into native code. So how can we make this process even faster?

The second browser war is all about JavaScript performance.

Which Browsers Support WebAssembly?

WebAssembly is supported by all major browsers: Chrome, Edge, Safari, Opera, and Firefox, including their mobile versions. You can verify support yourself by visiting https://caniuse.com/?search=WASM as shown in Figure 1-5.

As WebAssembly will become more and more important, we will see other browsers follow suit, but don’t expect Internet Explorer to support WASM.

WebAssembly and Mono

Mono is an open source implementation of the .NET CLI specification, meaning that Mono is a platform for running .NET assemblies. Mono is used in Xamarin (now called Multi-platform App UI, or MAUI for short) for building mobile applications that run on the Windows, Android, and iOS mobile operating systems. You can also use it to build applications for macOS, Linux, Tizen, and others. Mono also allows you to run .NET on Linux (its original purpose) and is written in C++. This last part is important because we saw that you can compile C++ to WebAssembly. So, what happened is that the Mono team decided to try to compile Mono to WebAssembly, which they did successfully. There are two approaches. One is where you take your .NET code and you compile it together with the Mono runtime into one big WASM application. However, this approach takes a lot of time because you need to take several steps to compile everything into WASM, not so practical for day-to-day development. The other approach takes the Mono runtime and compiles it into WASM, and this runs in the browser where it will execute .NET Intermediate Language just like normal .NET does. The big advantage is that you can simply run .NET assemblies without having to compile them first into WASM.

This is the approach currently taken by Blazor. In the beginning, Blazor used the Mono runtime, but they have now built their own .NET Core runtime for WebAssembly. But Blazor is not the only one taking this approach. For example, there is the Ooui project which allows you to run Xamarin.Forms applications in the browser. The disadvantage of this is that it needs to download a lot of .NET assemblies . This can be solved by using tree shaking algorithms which remove all unused code from assemblies. We will look at this in Chapter 15.

How Does It Work?

Let’s start with a simple razor file in Listing 1-1 which you can find when you create a new Blazor project (which we will do further on in this chapter, no need to type anything yet).

This file gets compiled into a .NET class (you’ll find out how later in this book) which is then executed by the Blazor engine. The result of this execution is a tree-like structure called the render tree . The render tree is then sent to JavaScript which updates the DOM to reflect the render tree (creating, updating, and removing HTML elements and attributes). Listing 1-1 will result in h1, p (with the contents set to the value of currentCount), and button HTML elements. When you interact with the page, for example, when you click the button, this will trigger the button’s click event which will invoke the IncrementCount method from Listing 1-1. The render tree is then regenerated, and any changes are sent again to JavaScript which will update the DOM. This process is illustrated in Figure 1-6.

This model is very flexible. It allows you to build Progressive Web Apps, and your app can be embedded in Electron desktop applications of which Visual Studio Code is a prime example.

Blazor Server

At the August 7, 2018, ASP.NET community standup (www.youtube.com/watch?v=7Eh_l7jEcCo), Daniel Roth introduced a new execution model for Blazor now called Blazor Server. In this model, your Blazor site is running on the server resulting in a way smaller download for the browser.

We just saw that Blazor WebAssembly builds a render tree using the .NET runtime running in the browser which then gets sent to JavaScript to update the DOM. With Blazor Server, the render tree is built on the server using regular .NET and then gets serialized to the browser using SignalR (we will look at SignalR in a later chapter). JavaScript in the browser then deserializes the render tree to update the DOM. Pretty similar to the Blazor WebAssembly model. When you interact with the site, events get serialized back to the server which then executes the .NET code, updating the render tree, and the changes get serialized back to the browser. I’ve illustrated this process in Figure 1-7. The big difference is that there is no need to send the .NET runtime and your Blazor assemblies to the browser. And the programming model stays the same! You can switch Blazor Server-side and Blazor WebAssembly with just a couple of small changes to your code.

Pros and Cons of the Blazor Server

Installing Blazor Prerequisites

Working with Blazor requires you to install some prerequisites, so in this section, you will install what is needed to get going.

Blazor runs on top of .NET , optionally providing the web server for your project which will serve the client files that run in the browser and run any server-side APIs that your Blazor project needs. .NET (previously known as .NET Core) is Microsoft’s cross-platform solution for working with .NET on Windows, Linux, and OSX.

You can find the installation files at www.microsoft.com/net/download. Look for the latest version of the .NET SDK (you’ll need at least version 6.0). Follow the installation instructions and install it on your machine, using Windows, OSX, or Linux.

Output should indicate that you installed the correct version. The version number should be at least 6.0.

Should the command’s output show an older version, you will need to download and install a more recent version of .NET SDK. These can run side by side so you will not break other .NET projects doing this.

Using Visual Studio

For people using Windows, Visual Studio (from now on, I will refer to Visual Studio as VS) is one of the integrated development environments (IDE) we will use throughout this book. If you are using OSX or Linux, you can use Visual Studio Code, and OSX users might prefer Visual Studio for Mac. With any one, you can edit your code, compile it, and run it all from the same application. And the code samples are also the same.

If you want to use Visual Studio, download the latest version of Visual Studio from www.visualstudio.com/downloads/. The Community Edition is free and should allow you to do everything done in this book.

Run the installer and make sure that you install the ASP.NET and web development role as shown in Figure 1-8.

After installation, run Visual Studio from the Start menu. Then open the Help menu and select About Microsoft Visual Studio. The About Microsoft Visual Studio dialog window should specify at least version 17.0.0 as illustrated in Figure 1-9.

Using Visual Studio Code

Visual Studio Code (VSC) is a free, modern, cross-platform development environment with an integrated editor, git source control, and debugger. The environment has a huge range of extensions available allowing you to use all kinds of languages and tools directly from VSC. So, if you don’t have access to (because you’re running a non-Windows operating system or you don’t want to use) Visual Studio, use VSC.

Install VSC from www.visualstudio.com/. Install using the defaults.

After installation, you should install a couple of extensions for Code, especially the C# extension. Start Code, and at the left side, select the extensions tab as shown in Figure 1-10.

You can search for extensions, so start with C# which is the first extension from Figure 1-11. This extension will give you IntelliSense and debugging for the C# programming language and .NET assemblies. You will probably get a newer version listed, so take the latest.

Click Install.

Understanding the Blazor Templates for VS/Code

Throughout this book, we will create several different Blazor projects. With .NET Core, we can use the command-line interface (CLI) to create all kinds of projects, including Blazor WebAssembly and Blazor Server.

With Blazor projects, you have a couple of choices. You can create a standalone Blazor project (using the blazorwasm template) that does not need server-side code. This kind of project known as Blazor WebAssembly has the advantage that you can simply deploy it to any web server which will function as a file server, allowing browsers to download your site just like any other site. We will look at deployment in a later chapter.

Or you can create a hosted project (adding the --hosted option) with client, server, and shared code. This kind of Blazor WebAssembly project will require you to host it where there is .NET Core support because you will execute code on the server as well, for example, to retrieve data from a database.

The third option is to run all Blazor code on the server (using the blazorserver template). In this case, the browser will use a SignalR connection to receive UI updates from the server and to send user interaction back to the server for processing.

In this book, we will use the second option (Blazor WebAssembly hosted on ASP.NET MVC Core) most of the time, but the concepts you will learn in this book are the same for all three options. You can even develop for Blazor WebAssembly and Blazor Server at the same time! Why? Because debugging support for Blazor WebAssembly is limited, so you develop with Blazor Server using all debugger features you know and love. But you can test everything with Blazor WebAssembly ensuring you can run everything in the browser later. This is the way I like to work. However, to pull this off, you need some experience with Blazor first, so keep reading.

Generating the Project with Dotnet CLI

This should build without any errors.

Open your browser on this address (here https://localhost:5001), and you are ready to play!

Generating Your Project with Visual Studio

Start Visual Studio and select Create a new project.

Type Blazor in the search box, and select the Blazor WebAssembly App project template as illustrated in Figure 1-12.

Click Next.

Name your project MyFirstBlazor, choose the location where the project should be generated, and click Next.

On the next screen, you can select the framework to use. Choose the latest version (at the time of writing, that is .NET 6.0), leave Authentication type set to None, check the ASP.NET Core hosted checkbox, and click Create. An example is shown in Figure 1-13.

Wait for Visual Studio to complete. Then build and run your solution by pressing F5. After a little while, the browser will open and display the Blazor application.

Running Blazor with Visual Studio Code

Or you can open VSC and then select File ➤ Open Folder….

When Code has loaded everything (be patient), it will pop a question as in Figure 1-14. Answer Yes. This will add a folder called .vscode with configuration files adding support for building and running the project from Code. If you already have a .vscode folder (because you copied an existing project, for example), you will not get this question.

Thanks to this integration with Visual Studio Code, you can simply press F5 to build and run your project.

The Server Project

Web applications are a bunch of files that get downloaded by the browser from a server. It is the server’s job to provide the files to the browser upon request. There is a whole range of existing servers to choose from, for example, IIS on Windows or Apache on Linux. ASP.NET Core has a built-in server known as Kestrel that you generated with the --hosted option, which you can then run on Windows, Linux, or OSX. This is the preferred option to use during development.

Would you like to see a detailed error page when the server has an uncaught exception? The UseDeveloperExceptionPage method which installs some error handling middleware takes care of that. Of course, you don’t need that in production (you should handle all exceptions correctly <grin>), so this middleware is only used when running in a development environment. How does the server know if you are running in development or release? The if statement you see here checks an environment variable called ASPNETCORE_ENVIRONMENT , and if the environment variable is set to Development, it knows you are running in development mode.

The Blazor bootstrap process requires a bunch of special files, especially dotnet.wasm (dotnet.wasm is the .NET runtime compiled as WebAssembly). This is served by the Blazor middleware, which is installed by the UseBlazorFrameworkFiles instruction. Later in this chapter, you will see why.

Look at the end of Listing 1-2. Here is another important middleware installed. The MapFallbackToFile("index.html") will return the index.html file which takes care of loading everything your Blazor application needs.

Using a Shared Project

The FetchData component downloads weather information from the server. These kinds of requests will be handled by the MVC middleware (MapControllers). We will discuss this in more detail in Chapter 6.

Understanding the Client Blazor Project

After this, there is another div; this is used to display errors in case your Blazor application has an uncaught exception.

This script will install Blazor by downloading dotnet.wasm. A little further we will look at this in more detail.

Listing 1-6. The index.html File

Layout Components

This component contains a div HTML element with two nested divs. The first nested div with class sidebar contains a single Blazor component: NavMenu. This is where your navigation menu gets defined. The sidebar will display a menu, allowing you to navigate between Home, Counter, and Fetch data. We will look in more detail at navigation and routing in Chapter 9.

The next nested div with class main has two parts. The first is the About link you see on every page. The second part contains the @Body; this is where the selected page will be shown. For example, when you click the Counter link in the navigation menu, the @Body will be replaced with the Counter component.

This is all for now, but the rest of the book will explain each part as we go along.

Debugging with Visual Studio

Now run your application in VS with the debugger by pressing F5. Be patient while your Blazor site starts to run (in Edge or Chrome!). Now you can put a breakpoint in your code, for example, on the IncrementCount method of the Counter component as in Figure 1-18, line 17. Simply click in the gray area left to your code (also known as the gutter) and a red dot will appear, indicating that the debugger will stop at this code.

Go back to your Blazor application and click the Counter’s Click Me button. The debugger should stop on the IncrementCount method. You can now examine the content of simple variables in the Locals window, like in Figure 1-19.

Debugging with Visual Studio Code

Start VSC. Ensure you have the Microsoft.AspNetCore.Razor.VSCode.BlazorWasmDebuggingExtension debugging extensions installed as in Figure 1-20.

You will also have to ensure that the JavaScript Preview Debugger has been enabled (by the time you are reading this, it might no longer be a preview feature). You can find this setting in VSC Settings like in Figure 1-21.

Open the folder containing the solution file. If it is the first time you open this folder with VSC, be patient, after a while, Figure 1-14 will pop up. Answer Yes. Also ensure Listing 1-11 is set up correctly like Visual Studio (this is actually independent of your IDE).

Now run your application in VSC with the debugger by pressing F5. Be patient while your Blazor site starts to run (in Chrome!). Now you can put a breakpoint in your code, for example, on the IncrementCount method of the Counter component as in Figure 1-22, line 16. Simply click in the area left to your code (also known as the gutter) and a red dot will appear, indicating that the debugger will stop at this code.

Go back to your Blazor application and click the Counter’s Click Me button. The debugger should stop on the IncrementCount method. You can now examine the content of simple variables in the Locals window, like in Figure 1-23.

Hot Reload with .NET CLI

As soon as you make the change, the browser will update itself, keeping the current count!

Save. Clicking the Increment button will not add 3 to the counter.

If you want to restart again, go back to the command line and press Ctrl-Shift-R.

Hot Reload with Visual Studio

At the time of writing this chapter, hot reload does not work yet for Blazor WebAssembly application with Visual Studio. But, by the time you are reading this, it should work.

An Apology

Who invented the null pointer? Tony Hoare did, and he apologized in 2009 and denoted this as his billion-dollar mistake (www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/):

I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.

Many object-oriented programming languages still use the null pointer , and C# is no exception. Some languages even treated null differently. For example, in Objective-C, when a pointer is null, the compiler would not invoke a method on it. And it would do this silently! Of course, you would not get a NullReferenceException, but it did skip an important piece of functionality.

Using Null in C#

Of course, this would break every existing C# application out there, so we need to enable this in our project properties. You can do this in Visual Studio using your project properties as shown in Figure 1-30.

This causes the compiler to set a nullable flag for every field, property, and method that is of (or returns) a reference type. You can inspect this flag in VS by hovering over it as shown in Figure 1-31.

The compiler then uses that flag to issue warnings if you would attempt to use a nullable reference type, for example, by getting the length of the string. Figure 1-32 will display a warning because the canBeNull reference can be null.

However, if we nest this in a condition as in Figure 1-33 where we check against null, the compiler will no longer issue a warning.

So the whole idea of nullable reference types is to make the compiler do the analysis and to issue a warning when we can have a possible null being used which would result in a NullReferenceException.

Using References

However, this does not mimic real life. There is another technique we can use.

The Null-Forgiving Operator

Sometimes you just know that a nullable reference is not null, and you want to tell the compiler about this. For this, we can use the null-forgiving operator by appending the nullable reference with an exclamation mark as in Figure 1-34. This sets the nullable flag to false, and the compiler is happy.

This is exactly the technique we will use to create Blazor components that have reference properties that we cannot initialize using a constructor.

Nullable Reference Types and .NET Libraries

Microsoft has gone through a lot of effort to make all their libraries support nullable reference types. I want you to realize that this is all compiler meta-data, so you can use the new libraries supporting nullable reference types with older projects; the compiler will simply ignore this meta-data. You can also use libraries that do not support this meta-data, but you will need to use the null-forgiving operator with a lot of methods. But do yourself a favor – get to use nullable reference types and your code will be shipped with a lot less bugs! You can learn more at https://docs.microsoft.com/en-us/dotnet/csharp/nullable-references.

One-Way Data Binding Syntax

On this page, you get a simple counter, which you can increment by clicking the button as illustrated in Figure 2-1.

Let’s look at the workings of this page. The currentCount field is defined in the @code section in Counter.razor. This is not a field that can be set from outside, so there is no need for the [Parameter] attribute, and we can keep it private.

Any time you click the button, the Blazor runtime sees that currentCount may have been updated, and it will automatically update the DOM with the latest value of currentCount.

Attribute Binding

You can also use this same syntax to bind the value of an HTML attribute.

Conditional Attributes

Try it. Clicking the button until the currentCount becomes 10 will disable the button by adding the disabled attribute to the button. As soon as currentCount falls below 10, the button will become enabled again (except there is no way you can do this for the moment).

Event Binding Syntax

Clicking the button will trigger the DOM’s click event, which then will call the IncrementCount method , which will cause the UI to be updated with the new value of the currentCount field. Whenever the user interacts with the site, for example, by clicking a button, Blazor assumes that the event will have some side effect because a method gets called, so it will update the UI with the latest values. Simply calling a method will not cause Blazor to update the UI. We will discuss this later in this chapter.

Event Arguments

In regular .NET, event handlers of type EventHandler can find out more information about the event using the sender and EventArgs arguments. In Blazor, event handlers don’t follow the strict event pattern from .NET, but you can declare the event handler method to take an argument of some type derived from EventArgs, for example, MouseEventArgs, as shown in Listing 2-10. Here, we are using the MouseEventArgs instance to see if the Ctrl key is being pressed and, if so, to decrement the currentCount field.

Using C# Lambda Functions

If you want to use a lambda function to handle an event, you need to wrap it in round braces.

Two-Way Data Binding Syntax

With two-way data binding, we will have the DOM update whenever the component changes, but the component will also update because of modifications in the DOM. The simplest example is with an <input> HTML element.

Build and run.

Change the value of the input, for example, 3. You should now be able to increment the currentCount with other values as in Figure 2-2.

Here, we are using the @bind syntax which is the equivalent of two different one-way bindings as shown in Listing 2-14.

This alternative syntax is very verbose and not that handy to use. Using @bind is way more practical. However, don’t forget about this technique; using the more verbose syntax can sometimes be a more elegant solution!

Binding to Other Events: @bind:{event}

Blazor will update the value in two-way data binding when the DOM’s onchange event occurs. This means that the increment field of the Counter component will be updated when the user changes the focus to another element, for example, the button. But maybe this is too late for you. Let’s look at how you can change the event that triggers data binding.

Preventing Default Actions

In Blazor, you can react to events, and the browser will also react to these. For example, when you press a key with the focus on an <input> element, the browser will react by adding the keystroke to the <input>.

Build and run again. Now pressing “+” will increment the input’s value as expected.

Stopping Event Propagation

In a browser, events propagate to the parent element, then to that parent element’s parent, etc. Again, generally this is desirable, but not always.

Build and run.

If you want to be able to turn this on and off from code, assign a bool expression to this attribute, just like preventDefault.

Formatting Dates

Currently, DateTime values are the only ones supporting the @bind:format attribute.

Creating the PizzaPlace Project

Create a new Blazor hosted project, either using Visual Studio or dotnet CLI. Refer to the explanation on creating a project in the first chapter if you don’t recall how. Call the project PizzaPlace. You get a similar project to the MyFirstBlazor project. Now let’s apply some changes!

With Visual Studio, you can also open your project’s properties like in Figure 2-3.

Out of the box, Blazor uses the popular Bootstrap 4 layout framework (https://getbootstrap.com/), including open-iconic fonts. Expect to see bootstrap and open-iconic (oi) CSS classes in the code samples. However, you can use any other layout framework, because Blazor uses standard HTML and CSS. This book is about Blazor, not fancy layouts, so we’re not going to spend a lot of time choosing nice colors and making the site look great. Focus!

In the server project, throw away WeatherForecastController.cs. We don’t need weather forecasts to order pizzas. In the shared project, delete WeatherForecast.cs. Same thing. In the client project, throw away the Counter.razor and FetchData.razor files from the Pages folder and SurveyPrompt.razor from the Shared folder.

Adding Shared Classes to Represent the Data

In Blazor, it is best to add classes holding data to the Shared project (unless you are building a Blazor application without a back-end server). These classes are used to send the data from the server to the client and later to send the data back. You might know these kinds of classes as models, or Data Transfer Objects (DTO).

What do we need? Since we will build a site around pizzas, creating a class to represent this makes sense.

Our application is NOT about editing pizzas yet, so I’ve made this class immutable, that is, nothing can be changed once a pizza object has been created. In C#, this is easily done by creating properties with only a getter. You can still set these properties, but only in the constructor.

As in real life, a restaurant’s menu is a list of meals, in this case, a pizza meal.

Please note that we just keep the pizza id in the Orders collection. You will learn why later.

There is another good reason to put all these classes into the Shared project. There is limited debugging for Blazor. By putting these classes into the Shared project, we can apply unit testing best practices on the shared classes because it is a regular .NET project and even use the Visual Studio debugger to examine weird behavior. The Shared project can also be used by other projects since it is a .NET Standard project, for example, a Windows or MAUI client!

Building the UI to Show the Menu

With these classes in place to represent the data, the next step is to build the user interface that shows the menu. We will start by displaying the menu to the user, and then we will enhance the UI to allow the user to order one or more pizzas.

The problem of displaying the menu is twofold: first, you need to display a list of data. The menu can be thought of as a list, like any other list. Secondly, in our application, we’ll need to convert the spiciness choices from their numeric values into URLs leading to the icons used to indicate different levels of hotness.

However, with razor, we can do even better. We can add this using statement to all the components at once!

The PizzaPlace menu is a list like any other list. You can display it by adding some razor markup in Index.razor to generate the menu as HTML as shown in Listing 2-36. I like to use comments to show the start and end of each section on my page. This makes it easier to find a certain part of my page when I come back to it later. In the next chapter, we will convert each section in its own Blazor component, making future maintenance a lot easier to do.

Converting Values

This converter function simply converts the name of the enumeration’s value from Listing 2-26 into the URL of an image file which can be found in the Blazor project’s images folder as shown in Figure 2-4. Add this folder (which can be found in this book’s download) to the wwwroot folder.

Adding Pizzas to the Shopping Basket

Look at the @onclick event handler (@onclick="@(() => AddToBasket(pizza))") for the button from Listing 2-36. Why is this event handler using a lambda? When you order a pizza, you want of course to have your chosen pizza added to the basket. So how can we pass the pizza to AddToBasket from Listing 2-38? By using a lambda function, we can simply pass the pizza variable used in the @foreach loop to it. Using a normal method wouldn’t work because there is no easy way to send the selected pizza. This is also known as a closure (very similar to JavaScript closures) and can be very practical!

Run the application. You should see Figure 2-5.

When you click the Add button, you’re adding a pizza to the shopping basket. But how can we be sure (since we’re not displaying the shopping basket yet)?

We can use the debugger, just like any other .NET project! Add a breakpoint to the AddToBasket method as in Figure 2-6, and run your project with the debugger. Wait for the browser to display the PizzaPlace page and click one of the Add buttons. The debugger should stop the breakpoint. Now you can inspect the argument of the AddToBasket method, which should be the selected pizza. Most of the usual debugging stuff works with Blazor!

Displaying the Shopping Basket

The next thing on the menu (some pun intended) is displaying the shopping basket. We are going to use a feature from C# called tuples . I will explain tuples in a moment.

Most of this stuff is very similar, but now we are iterating over a list of tuples (keep reading, a very handy new feature in C# https://docs.microsoft.com/dotnet/csharp/tuples).

Tuples are very similar to anonymous types from C#, in that they let you store and return intermediate multi-part results without you having to build a helper class.

We are using LINQ’s Select to iterate over the list of orders (which contain pizza ids). To display the pizza in the shopping basket, we need a pizza, so we convert the id to a pizza with the GetPizza method from the Menu.

The LINQ Select method has two overloads, and we’re using the overload taking an element from the collection (id) and the position in the collection (pos). We use these to create tuples. Each tuple represents a pizza from the basket and its position in the basket! We could have done the same, creating a little helper class with the pizza and position, but this is now done for us! And it is efficacious, using less memory than a class because it is a value type!

Run the application and order some pizzas. You should see your current order similar to Figure 2-7.

Entering the Customer Information

Of course, to complete the order, we need to know a couple of things about the customer, especially we need to know the customer’s name and address because we need to deliver the order.

This adds three <label>s and their respective <input>s for name, street, and city.

The PlaceOrder method doesn’t do anything useful yet; we’ll send the order to the server later. This does however show a valid debugging technique in Blazor, where we place Console.WriteLine statements to see what gets executed.

Run the application and enter your details, for example, as in Figure 2-8.

Debugging Tip

Even with modern debuggers, you want to see the State object because it contains the customer’s details and order as you are interacting with the application. Will we send the correct information to the server when we press the Checkout button? For this, we’ll use a simple trick by displaying the State on our page, so you can review it at any time.

Run your project. As you interact with the page, you’ll see State change with an example shown in Figure 2-9.

It should be obvious that we remove this debugging feature when the page is ready . For example, you could add an #if DEBUG inside the ToJson method to only make it work outside release builds.

Letting Entities Validate Themselves

Classes like Customer should validate themselves because they have the best knowledge about the validity of their properties. .NET has a couple of built-in validation mechanisms, and here we are going to use the standard System.ComponentModel.DataAnnotations. In Chapter 3, we will look at using other validation mechanisms. With data annotations, you add attributes to your entity's properties, indicating what kind of validation is required.

Start by adding the System.ComponentModel.Annotations package to the PizzaPlace.Shared project.

Using FormField and InputText to Enable Validation

Blazor comes with some built-in components that will perform validation for you. Replace the customer entry UI with Listing 2-49. Here, we replace the <input> HTML elements with built-in editing components. The EditForm component wraps around all the InputText components and will render as the HTML <form> element. The EditForm component has a Model property which you set to the instance you need to validate. When the user clicks the Submit button, the EditForm component performs validation, and when there are no validation errors, it will call the OnValidSubmit event.

Use the InputText component for each field, binding one to each property of the model using the @bind-Value attribute. This is the syntax used to tell the component to use two-way data binding between the Value property of the InputText component and the property of the model. Listing 2-49 has three such InputText components, one for Name, Address, and City.

Showing Validation Errors

Run the application again, and click the Checkout button. You will see that the inputs now receive a red border, because of validation errors. As a user, you would now wonder what you did wrong. So we need to show some error as feedback.

Build and run the PizzaPlace project. Click the Checkout button. You should get validation errors as shown in Figure 2-10. Blazor validation also adds some styles, and by default, this will put a red border around inputs with validation errors.

Note that the Checkout button does not invoke the PlaceOrder method if there are validation errors.

Now enter a name, street, and city. You should see the validation errors go away. You will also see green borders appear since the inputs are now valid.

You can also use a ValidationSummary component which shows all the validation errors together as an unordered list. For example, you can add the ValidationSummary component below the DataAnnotationsValidator as in Listing 2-52. This will show all validation errors as in Figure 2-11.

<EditForm Model="@State.Basket.Customer"

          OnValidSubmit="PlaceOrder">

  <DataAnnotationsValidator />

  <ValidationSummary/>

Listing 2-52

Using the ValidationSummary Component

Customizing the Validation Feedback

When you enter a value in an InputText element (or one of the other input components), Blazor validation gives you feedback about the validity of the value by adding certain CSS classes. Let us have a look at how this is implemented. Run the PizzaPlace project, right-click one of the inputs, and then select Inspect from the browser’s menu.

So, if you want to customize how your feedback looks like, you customize these CSS rules. For example, you can use the following CSS to wwwroot/css/app.css from Listing 2-58 to make validation look like Figure 2-12.

.valid.modified:not([type=checkbox]) {

  border-left: 5px solid #42A948; /* green */

}

.invalid {

  border-right: 5px solid #a94442; /* red */

}

.validation-message {

  color: #a94442;

}

Listing 2-58

Some Custom CSS Rules to Change Validation Feedback

Examining the SurveyPrompt Component

Look at the Razor markup. This is a simple Blazor component that displays an icon in front of the Title as shown in Figure 3-1 and then displays a link to the survey (a real survey which you should take – this will show Microsoft that you’re interested in Blazor).

The @code section simply contains a property Title that uses one-way data binding for rendering in the component. Do note the [Parameter] attribute on the Title property. This is required for components that want to expose their public properties to the parent component. This way, we can pass data to nested components, for example, how the Index component passes the Title to the SurveyPrompt component.

Building a Simple Alert Component with Razor

Let us build our own Blazor component that will show a simple alert. Alerts are used to draw the attention of the user to some message, for example, a warning.

Creating a New Component with Visual Studio

Open the MyFirstBlazor solution. Right-click the Pages folder and select Add ➤ New Item…. The Add New Item window should open as in Figure 3-2.

Select Razor Component and name it Alert.razor. Click Add.

Implementing the Alert Component

Remove all existing content from Alert.razor and replace it with Listing 3-3. Let us have a look at this component.

The first line in the Alert component uses an @if to hide or show its inner content. This is a common technique if you want to conditionally display content. So, if the Show public property (actually parameter) is false, the whole component is not shown. This allows us to “hide” the component until needed.

Our Alert component will show some content in a <div> element as an alert (using bootstrap styles), so how do we pass this content to the Alert component? Inside the @if, there is a <div> element with @ChildContent as its child. You use @ChildContent if you want to access the nested element in the Alert component, as you’ll see when we use the Alert component in Listing 3-4.

Blazor dictates that this property/parameter should be named @ChildContent and it needs to be of type RenderFragment because this is the way the Blazor engine passes it (we will look at this later in this chapter).

@if (Show)

{

  <div role="alert">

    @ChildContent

  </div>

}

@code {

  [Parameter]

  public bool Show { get; set; }

  [Parameter]

  public RenderFragment ChildContent { get; set; } = default!;

}

Listing 3-3

The Alert Component

Note

The default Blazor templates use Bootstrap 4 for styling. Bootstrap (http://getbootstrap.com) is a very popular CSS framework, originally built for Twitter, giving an easy layout for web pages. However, Blazor does not require you to use bootstrap, so you can use whatever styling you prefer. In that case, you would have to update all the razor files in the solution using the other styles, just like in regular web development. In this book, we will use bootstrap, simply because it is there.

Go back to Index.razor to add the element.

As you start to type, Visual Studio and Code are smart enough to provide you with IntelliSense, as illustrated in Figure 3-3, for the Alert component and its parameters!

Complete the Alert and add a button as in Listing 3-4.

@page "/"

<h1>Hello, world!</h1>

<Alert Show="@ShowAlert">

  <span aria-hidden="true"></span>

  <strong>Blazor is so cool!</strong>

</Alert>

<button @onclick="ToggleAlert">Toggle</button>

@code {

  public bool ShowAlert { get; set; } = true;

  public void ToggleAlert() => ShowAlert = !ShowAlert;

}

Listing 3-4

Using Our Alert Component in Index.razor

Inside the <Alert> tag, there is a <span> displaying a checkmark icon using the open-iconic font and a <strong> element displaying a simple message. These will be set as the @ChildContent property of the Alert component.

Build and run your project. When you click the <button>, it calls the ToggleAlert method which will hide and show the Alert as in Figure 3-4.

Creating a DismissibleAlert Component

If you haven’t done so yet, open the MyFirstBlazor solution. With Visual Studio, right-click the Pages folder and select Add ➤ New Item…. The Add New Item dialog should open as shown in Figure 3-2. This time, select Razor Component and name it DismissibleAlert.razor. Also, add a new C# class, and call the file DismissibleAlert.razor.cs.

With Visual Studio Code, right-click the Pages folder, select New File, and name it DismissibleAlert.razor. Do this again to create a new file called Dismissible.razor.cs.

There is no @code section, because you will write this in the .cs file.

Do note that this is a partial class with the same name as the Blazor component! So instead of putting your code in the @code section of a razor file, you can put the code in a partial class.

Which model is best? I don’t think either one is better than the other; it is more a matter of taste. Choose the one you like. I do like the code separation model a little more (my personal opinion) because I think the C# editor has better features for keeping my code maintainable and clean.

Adding a Timer Component

Start by adding a new class called Timer to the Pages folder as shown in Listing 3-8. The timer will not have any visual part, so we don’t even need a .razor file to build the view.

A Blazor component is a class that inherits the ComponentBase class. Since we want to use the Timer class as a Blazor component, we need to inherit from ComponentBase .

Run the application and wait at least 5 seconds. The alert does not hide! Why?!

Look at the markup, which is in Listing 3-9, for Dismissible. It shows the component based on the Show parameter, and this one gets set through data binding. Does the ToggleAlert method get called? Run the Blazor website again, and immediately open the browser’s debugger on the console tab. After a little while, you should see the Console.WriteLine output appear. So the ToggleAlert method does get called.

Think about this. We invoke a method asynchronously using a Timer. When the timer fires, we set the Index component ShowAlert property to false. But we still need to update the UI. You can manually trigger the UI to update by calling the StateHasChanged method .

This is very important! The Blazor runtime updates the UI automatically when an event triggers, like the button click. The Blazor runtime also updates the UI for its own asynchronous methods, but not for other asynchronous methods like Timer.

Run again and wait, and after 5 seconds, the alert disappears!

To be honest, I don’t like the previous solution to our problem. Because a child component calls the ToggleAlert method , we manually need to call StateHasChanged . Is there no better way? And we haven’t even solved another problem. When the user dismissed the alert before the timer triggered the Tick method, it should reappear after 5 seconds because it will set ShowAlert back to true!

We will fix both problems, but first, we need to understand two-way data binding between components.

Using Two-Way Data Binding Between Components

When the user clicks the Dismissible component’s close button, it sets its own Show property to false, as intended. The problem is that the parent Index component’s ShowAlert stays true. Changing the value of the Dismissible local Show property will not update the Index component’s ShowAlert property. What we need is two-way data binding between components, and Blazor has that.

With two-way data binding, changing the value of the Show parameter will update the value of the ShowAlert property of the parent and vice versa.

Properties that support two-way data binding need a way to tell the parent that the property has changed. The child component uses for that a delegate, so the parent component through the Blazor runtime can install its own change handler (just like an event) when the property has changed. This change handler will then update the parent component’s data bound property. The child component is responsible for invoking the Changed delegate when the property changes.

Open the Dismissible class and its implementation to match Listing 3-12. There are two changes. First of all, the Show property now uses the “full” implementation of a property, because we need to implement the setter that it will call the ShowChanged delegate when its value changes.

Whenever someone or something changes the Show property’s value, the property’s setter triggers the ShowChanged delegate. This means the parent component can inject some code (which it does for you when you use two-way data binding) into the ShowChanged delegate property which will invoke when the property is changed (internally or externally).

Now, when the Dismissible Show property changes, Blazor will update the parent's ShowAlert property because we are using two-way data binding.

We still need to fix the problem when the Timer fires.

Run. Wait 5 seconds.

The Alert should automatically hide as illustrated in Figures 3-5 and 3-6.

Should your project still not update, you can debug a client-side Blazor project by adding breakpoints or some Console.WriteLine statements. These will appear in the browser’s console window. You can see examples of this in the book’s code which you can download from the Apress site.

Using EventCallback<T>

Now, with the DismissibleAlert component from the previous section, we have been using two-way data binding between components with the @bind-Show syntax, and we used the ShowChanged callback to notify the parent component that the Show property has changed. To make the parent update its UI, we also added a call to StateHasChanged when the parent’s ShowAlert property gets modified. But there is a better way!

Blazor has the EventCallback type for this, which was added to Blazor in .NET Core 3.0 Preview 3 (https://github.com/aspnet/AspNetCore/issues/6351). The big difference between Action<T> and EventCallback<T> is that the latter will invoke StateHasChanged for you!

So instead of using an Action<T> delegate, we use the EventCallback<T> type. First of all, this type is a value type, so we don’t need to check for null. And instead of an Invoke method, it has an InvokeAsync method which solves some special problems which are not important at this point in time.

If you want to learn more about these problems, open your browser on https://github.com/dotnet/aspnetcore/issues/6351.

Build and run. Wait 5 seconds. The alert should hide!

In general, you should prefer EventCallback<T> over normal delegates for parent-child communication, such as events and two-way data binding. There are exceptions to the rule (e.g., the fact that EventCallback triggers component, re-rendering might be a problem, and then using a delegate can be the solution).

Using the CascadingValue Component

When you click the Inc button of GrandChild, the CounterData’s Count property increments. The GrandMother component wants to display this value every time it gets incremented, so CounterData notifies the GrandMother of changes. The GrandMother component subscribes to these changes and calls StateHasChanged to update itself. How the shared object handles this notification is up to you; for example, CounterData uses a delegate. You could also use INotifyPropertyChanged . If you’re not familiar with this interface, it is used in a lot of .NET applications to notify interested parties that a property has changed. For example, Windows Presentation Foundation (WPF) heavily relies on this interface. If you would like to learn more, any good book on WPF will explain this, or you can find more information at https://docs.microsoft.com/dotnet/api/system.componentmodel.inotifypropertychanged.

Resolving Ambiguities

Life Cycle Overview

The LifeCycle component gets constructed (constructor called), and then Blazor calls the SetParametersAsync method . This method normally will result in the parameter setters being called, and that is why we see the Counter property’s output.

Then the Blazor runtime calls the OnInitialized method (and the asynchronous OnInitializedAsync which I left out for simplicity). After this, the OnParametersSet method is called (and also the asynchronous OnParametersSetAsync method). Now the component is ready to be rendered, and the Blazor runtime renders it. Finally, rendering the OnAfterRender method is called which gets passed a Boolean which is true on the first render.

This whole process is illustrated in Figure 3-7.

Because I clicked the Increment button of the Index component, it invokes the click handler and then re-renders itself. But first it sets the parameters on the LifeCycle component which results in the SetParametersAsync method being called again (which sets the Counter parameter). After this, it invokes the OnParametersSet method to indicate all parameters have been updated (and also the asynchronous OnParametersSetAsync method).

Now, should the Blazor runtime render the component? For this, it calls the ShouldRender method , and if this returns true, it will render the LifeCycle component (and then the OnAfterRender method).

Clicking the Increment button results in that sequence again.

Now let us look at each of these methods individually.

SetParametersAsync

If you need to execute some code before the parameters are set, you can override the SetParametersAsync method . The default implementation of the SetParametersAsync method will set each [Parameter] and [CascadingParameter] that has a value in the ParameterView argument. Other parameters (that don’t have a value in ParameterView) are left unchanged.

You can find the parameters in the ParameterView argument which behaves like a dictionary. Let’s look at an example in Listing 3-27. This example uses the SetParametersAsync method to inspect the parameters, looking for a “Counter” parameter. If this parameter is even, we call the base method; otherwise, we don’t do anything, resulting in an even valued Counter.

There is one snag; when you don’t call the base method, the UI doesn’t update, so you should call StateHasChanged if you want the component to update. Initially, our LifeCycle component could receive an odd value, and that is why we call StateHasChanged for the first time.

OnInitialized and OnInitializedAsync

When your component has been created and the parameters have been set, the OnInitialized and OnInitializedAsync methods are called. Implement one of these methods if you want to do some one-time extra initialization after the component has been created, for example, fetching some data from a server like the FetchData component from the project. The OnInitialized methods are only called once, right after the creation of the component.

OnParametersSet and OnParametersSetAsync

When you need one or more parameters to look up data after a change to the parameters, you use OnParametersSet or OnParametersSetAsync instead of the OnInitialized/OnInitializedAsync methods. Every time data binding updates one or more of your parameters, these methods get called again, so they are ideal for calculated properties, filtering, etc. For example, you could have a DepartmentSelector component that allows the user to select a department from a company and another EmployeeList component that takes the selected department as a parameter. The EmployeeList component can then fetch the employees for that department in its OnParametersSetAsync method.

ShouldRender

The ShouldRender method returns a Boolean value, indicating if the component should be re-rendered. Do realize that the first render ignores this ShouldRender method, so a component will render at least once. The default implementation always returns true. You want to override this method to stop the component from re-rendering.

OnAfterRender and OnAfterRenderAsync

The OnAfterRender and OnAfterRenderAsync methods are called after Blazor has completely rendered the component. This means that the browser’s DOM has been updated with changes made to your Blazor component. Use these methods to invoke JavaScript code that needs access to elements from the DOM (which we will cover in the JavaScript chapter 10 ). This method takes a Boolean firstRender argument, which allows you to attach JavaScript event handlers only once.

IDisposable

If you need to run some cleanup code when your component is removed from the UI, implement the IDisposable interface. You can implement this interface in razor using the @implements syntax, for example, in Listing 3-25. Normally, you put the @implements at the top of the .razor file, but if you use code separation, you can also declare it on the partial class.

Most of the time, dependency injection will take care of calling Dispose, so generally, you won’t need to implement IDisposable if you only need to dispose of your dependencies.

A Word on Asynchronous Methods

When the Blazor runtime calls asynchronous methods like OnInitializedAsync and OnParametersSetAsync, it will await this method and will also render the component. The only exception to this is the OnAfterRenderAsync method, which will not trigger a render (otherwise, this will cause an infinite render loop).

Creating a Component to Display a List of Pizzas

Open the PizzaPlace Blazor project from the previous chapter. You can also start with the code examples from this book; look for Chapter 2 which contains the finished version. Start by reviewing Index.razor. This is our main component, and you can say that it has three main sections: a menu, a shopping basket, and customer information.

The menu iterates over the list of pizzas and displays each one with a button to order. The shopping basket also displays a list of pizzas (but now from the shopping basket) with a button to remove it from the order. Looks like both have something in common; they need to display pizzas with an action you choose by clicking the button. So let’s create a component to display a list of pizzas, using a nested component to display a pizza’s details.

We have also seen that we can split components into a razor file with the markup and a C# file with the code. Let us do that here!

The PizzaItem component will display a pizza, so it should not come as a surprise that it has a Pizza parameter. This component also displays a button, but how this button looks and behaves will differ where we use it. And that is why it has a ButtonTitle and ButtonClass parameter to change the button’s look, and it also has a Selected event callback of type EventCallback<Pizza> which gets invoked when you click the button. Do you remember why we are using EventCallback<T> instead of Action<T>? Do note that this component does one thing well, and only one thing: display the pizza and allow an action on the pizza by clicking the button.