How to Create C# Client Web Apps With Microsoft’s Blazor Web Framework – CloudSavvy IT

Blazor is the latest feature of ASP.NET Core, Microsoft’s 20 year old web framework. Despite being old, Microsoft still maintains it, and ASP.NET has been consistently improving along with C# and the .NET runtime as a whole.

Razor pages, and ASP.NET’s old MVC model, both allow you to generate data-driven HTML pages using C#. That’s been around forever, but what it’s always lacked is interactivity. It’s pretty hard to make a web app when you have to reload the page to view changes.

So, Blazor solves that by directly linking the server and client with a library that can modify the DOM at runtime, and brings in many of the component lifecycle methods and update handlers that you’d expect out of a framework intended to compete with React.

And, with Razor page’s minimalist syntax, it makes coding in Blazor a breeze:

Blazor has two main modes of operation, the coolest of which is Blazor Client, which packages .NET itself into a framework that can be run entirely on WebAssembly. WASM is basically MSIL for the web; it’s a lightweight binary instruction format that any language can compile to, even “desktop” languages like C++ and Rust.

Blazor can also be used in a “hybrid mode” using prerendering. Blazor WASM can display raw HTML while the framework loads, usually used for a loading bar or spinner wheel. But, if you host the app from ASP.NET, you can render the Razor pages from the server before you even send the app to the client.

This works perfectly, with the catch that the page will not become interactive until Blazor actually loads. It usually only takes a second though so this isn’t really an issue, besides some quirks with reloading data twice.

Let’s take a tour of the application. Starting with the client, the main entry point is Program.cs, which creates the WebAssemblyHost, adds the root App.razor component, then builds and runs the app.

Technically, the entry point is wwwroot/index.html, which loads Blazor’s JavaScript file, shows a loading page while Blazor initializes, and shows an error message if it doesn’t.

Before sitting down to code, we need to fix something. For some reason, Microsoft’s default color choice for C# HTML directives in Razor pages is using what is perhaps the worst color combination imaginable—light purple text on a light tan background.

Luckily you can change it from Tools > Options:

Under Environment > Fonts and Colors, select “Razor Directive” and change the background color to something more reasonable. You probably still want it to stand out, so I just chose pure black, which will be noticeable but non-intrusive.

You’ll also need to change “HTML Server-Side Script,” (which is technically now an outdated name considering Blazor WebAssembly’s existence).

And with that simple fix, you can save your eyeballs hours of pain.

The last file you’ll want to check out is on the client, FetchData.razor. This is where the client actually consumes the server-side API, with the following data-driven page:

This is a fairly complex Razor page, so it’s a good example for us to break down here.

To start, it specifies a manual override for the page route with @page "/fetchdata". It then imports the shared models from the shared project, and also uses dependency injection to give it an HttpClient, which was set up in Program.cs.

We’ll skip down to the bottom to explain this first—the @code block contains the actual C# code for this page. In it, there’s a private variable called forecasts. This is initially null, but when the page is initialized, it makes a web request to grab the data from the API and deserialize it.

When that variable is updated, Blazor detects the change and re-renders the page. The page itself is everything in between, which starts with a header and description, but then contains an @if statement. This is C# conditional HTML, and in this case is used to show loading text while Blazor is making the request to the API. Then, once it finishes and re-renders, forecasts won’t be null, and it will render the table that will do @foreach element in the list, and render a table row.

Using this, you can render dynamic content from your models. To support more advanced CRUD operations, and more dynamic UIs, you will need to use buttons and inputs. You can use <button> tags with an @onclick attribute, which takes a method reference.

Extremely simple. There’s a site.css master file, but for component level styling, just create a .razor.css file for each Razor page:

index.razor
index.razor.css

Blazor will automatically create a scoped CSS file that applies the settings from each Razor page to only that Razor page:

<link href="https://www.cloudsavvyit.com/11962/how-to-create-c-client-web-apps-with-microsofts-blazor-web-framework/BlazorWebAssemblyTest.Client.styles.css" rel="stylesheet" />

/* /Pages/Counter.razor.rz.scp.css */
h1[b-3xxtam6d07] {
    color: brown;
}

Regardless of whether you go with Blazor Server or Blazor Desktop, you have full JavaScript interoperability, such as calling JS functions from managed code:

private async Task ConvertArray()
{
    text = new(await JS.InvokeAsync<string>("convertArray", quoteArray));
}

And calling .NET from JS:

DotNet.invokeMethodAsync('{ASSEMBLY NAME}', '{.NET METHOD ID}', {ARGUMENTS});

You can actually use all NPM packages with Blazor, though you should prefer a NuGet package most of the time if it’s an option.

One of the most important problems with web apps, especially single page web apps (SPWAs), is routing. Each Razor page has a default route according to its name, but you can override this, and you can also add multiple page routes to each Razor page. The router will match each one separately and still serve the same file.

However, if you want to serve different content depending on what URL you’re on, things get a little complicated. The simplest solution would just be define a @page route for each string you want to add. This works the first time, but because of the way Blazor handles updates, it won’t refresh the page when navigating to a new URL because the parameters haven’t changed. You can still use this to define multiple spellings of the same page, as long as those pages don’t link to each other.

The solution to the SPWA problem is to use parameter based routes whenever you want to catch multiple options and link between them. Parameters can be defined in brackets:

This particular setup is for the root page. If you’re concerned that it’s going to match other pages like /error since it’s configured to match anything after root, don’t worry, Blazor will match other pages that are strictly defined before falling back to using parameter-based routes. However, you can’t have multiple parameter routes on the same root route without getting an ambiguous route error.

In my case, I wanted to navigate the user to a new page with an argument. You can do this by accessing the NavigationManager and calling NavigateTo:

NavManager.NavigateTo("/search/" + searchValue);

Blazor is a truly unique framework among an ocean of JavaScript-based React clones, and with Microsoft behind it, it has a bright future. We mentioned earlier that Microsoft had plans for Blazor Desktop, which is coming in late 2021.

Blazor Desktop will function a lot like Electron does, where it launches your app in a Chromium container with some bindings for desktop functionality. Except, instead of using Chromium, Blazor Desktop is going to use native based WebViews, and run the .NET code directly on the machine.