DEV Community: Jon Hilton

Edit and Replay your network requests, direct from the browser

Jon Hilton — Mon, 07 Sep 2020 00:00:00 +0000

You know how it goes; you build your shiny new feature using Blazor, React, Vue, <insert framework here>.

You test locally; everything works as it should.

Then you push to production and…

… everything is broken!

Any number of things can break your app in prod but one of the biggies is data coming back (or being posted) via your network calls which doesn’t match what you expected.

For some time we’ve been able to inspect those network requests via the browser’s Dev Tools, to see what’s really going on.

You can inspect the request, check what parameters are being sent across, then look at the response and inspect the resulting data to see why your feature might be working the way it is.

But, what if you want to play with that request, tweak it’s parameters, or just replay the request, without having to drive everything from the UI?

Microsoft Edge now includes an Edit and Replay feature comes in, and it’s pretty darn useful.

So long as you’re using the new (actually really good) Chromium version of Edge, you can enable the shiny new Network Console for your browser.

With that, head over to any network request in the Dev Tools, right-click and select Edit and Replay and…

The Network Console springs into life and shows you the request, including things like Query parameters, the request Body and Auth tokens etc.

From here you can click Send to replay the request, at which point you can easily inspect the response for that request…

Then you can download the resulting json, or just edit the request and try again.

There are of course other ways to achieve similar results. I’ve been a big fan of a tool called Insomnia in recent years.

But, for testing authenticated requests it was always a bit of a pain to locate the JWT auth token, copy it and paste it across to Insomnia, then set up the request etc.

Now, with a couple of clicks you can replay requests right there in the browser, Auth tokens and everything!

It’s worth noting this is an “Experimental Feature so expect a few bugs here and there, but overall this looks like a big step forward for testing your client applications.

Check out this post by Microsoft for all the details (including how to enable this in Edge).

Make a responsive Navbar with Blazor and Tailwind?

Jon Hilton — Tue, 04 Aug 2020 00:00:00 +0000

You’ve no doubt seen the “hamburger” icon many, many times.

For example, head over to Tailwind’s docs, and you’ll see a full menu (on the left) if you’re using a big enough screen…

Knock that down to a smaller resolution though and the menu disappears, to be replaced by an icon in the top-right corner.

When you click that the nav menu appears…

Build it using Blazor

So how can you build this using Tailwind and Blazor?

Well it turns out most of the work here is actually the CSS, with just a tiny bit of code needed with Blazor to make it work.

In preparation I’ve:

Already configured this example Blazor app to use Tailwind CSS
Removed all references to Bootstrap
Modified the MainLayout.razor and NavMenu.razor components to use flex as a simple starting layout for our example application

MainLayout.razor

<div class="flex flex-col min-h-screen">
  <NavMenu/>
  <div class="p-4">
    @Body
  </div>
</div>

NavMenu.razor

<div class="p-6 bg-blue-500 text-white">
  <h1>Your site!</h1>
</div>

Which renders this:

Mobile first

Let’s be well-behaved developers and focus on making this work for mobile first!

We want to display a hamburger icon in the top-right of the nav bar.

First, we can add the icon to the existing HTML to see how it looks…

<h1>Your site!</h1>
<button>
<svg class="h-6 w-6 fill-current" viewBox="0 0 24 24">
<path fill-rule="evenodd"
d="M4 5h16a1 1 0 0 1 0 2H4a1 1 0 1 1 0-2zm0 6h16a1 1 0 0 1 0 2H4a1 1 0 0 1 0-2zm0 6h16a1 1 0 0 1 0 2H4a1 1 0 0 1 0-2z"/>
</svg>
</button>

Which renders:

To pull that over to the right we can use CSS’s ever-mysterious (but actually really useful) flexbox.

<div class="p-6 bg-blue-500 text-white">
 <div class="flex justify-between">
 <h1>Your site!</h1>

 <button>
 <svg class="h-6 w-6 fill-current" viewBox="0 0 24 24">
 <path fill-rule="evenodd"
 d="M4 5h16a1 1 0 0 1 0 2H4a1 1 0 1 1 0-2zm0 6h16a1 1 0 0 1 0 2H4a1 1 0 0 1 0-2zm0 6h16a1 1 0 0 1 0 2H4a1 1 0 0 1 0-2z"/>
 </svg>
 </button>
 </div>
</div>

By wrapping everything in a div we can use flex and justify-between to arrange all the elements within our nav along the x-axis, with equal space between them.

This essentially pulls the first item to the left, and the next item to the right.

Now what about the actual menu with all our nav items?

In this mode (mobile) we want to show a simple list below the nav bar itself (eventually we’ll trigger this by clicking the hamburger icon).

I’ll add the nav links at the end of the NavMenu.razor component.

<div class="p-6 bg-blue-500 text-white">
  <div class="flex justify-between">
  <h1>Your site!</h1>
  <button>
    <svg class="h-6 w-6 fill-current" viewBox="0 0 24 24">
    <path fill-rule="evenodd"
d="M4 5h16a1 1 0 0 1 0 2H4a1 1 0 1 1 0-2zm0 6h16a1 1 0 0 1 0 2H4a1 1 0 0 1 0-2zm0 6h16a1 1 0 0 1 0 2H4a1 1 0 0 1 0-2z"/>
    </svg>
  </button>
</div>
 <ul class="flex flex-col">
   <NavLink class="" href="/">Home</NavLink>
   <NavLink class="" href="/counter">Counter</NavLink>
   <NavLink class="" href="/fetchdata">Fetch Data</NavLink>
 </ul>
</div>

flex comes in handy again here. Without this and flex-col our nav links would appear next to each other.

With flex-col this switches to them being arranged in a column, vertically like so.

Now this is OK, but we probably want to make it look a little nicer. The following tweaks are entirely subjective depending on what you’re aiming for but here’s may attempt at tidying this up.

<div class="bg-blue-500 text-white">
  <div class="flex items-center justify-between p-4">
    <h1>Your site!</h1>
      <button>
        <svg class="h-6 w-6 fill-current" viewBox="0 0 24 24">
        <path fill-rule="evenodd"
d="M4 5h16a1 1 0 0 1 0 2H4a1 1 0 1 1 0-2zm0 6h16a1 1 0 0 1 0 2H4a1 1 0 0 1 0-2zm0 6h16a1 1 0 0 1 0 2H4a1 1 0 0 1 0-2z"/>
     </svg>
    </button>
  </div>
  <ul class="flex flex-col bg-gray-700 px-4 py-2">
    <NavLink class="" href="/">Home</NavLink>
    <NavLink class="" href="/counter">Counter</NavLink>
    <NavLink class="" href="/fetchdata">Fetch Data</NavLink>
  </ul>
</div>

Adjust padding

I moved the padding from the outermost div to the ‘inner’ div, and knocked it down from p-6 to p-4.

The problem with the padding being on the outermost div is it affects everything, including the ul list of links. This means you can’t get the links to go right up to the edges of the div, because of the padding.

So I scrapped that and added padding to the div which contains the main heading and hamburger icon instead.

Adjust vertical alignment of heading and hamburger

I used items-center to make sure the heading and hamburger icon are vertically centered in their containing div.

Added some style to the nav links

Finally I’ve given the ul a background colour and a little padding (px-4 to make sure the links line up with the heading in the div above).

And here’s how it looks:

Not too shabby!

Make the links appear or disappear on click

Before we go any further let’s make those links only appear when you click the icon.

First we’ll add a little C# code to NavMenu.razor.

@code
{
  private bool _menuVisible = false;
  private void ToggleMenu()
  {
    _menuVisible = !_menuVisible;
  }
}

With this we can toggle a boolean _menuVisible on and off.

Now to use that in the markup.

<div class="bg-blue-500 text-white">
  <div class="flex items-center justify-between p-4">
  <h1>Your site!</h1>
  <button @onclick="ToggleMenu">
    <svg class="h-6 w-6 fill-current" viewBox="0 0 24 24">
    <path fill-rule="evenodd"
d="M4 5h16a1 1 0 0 1 0 2H4a1 1 0 1 1 0-2zm0 6h16a1 1 0 0 1 0 2H4a1 1 0 0 1 0-2zm0 6h16a1 1 0 0 1 0 2H4a1 1 0 0 1 0-2z"/>
    </svg>
  </button>
</div>
@{
  var menuVisibleClass = _menuVisible ? "" : "hidden";
}

<ul class="@($"flex flex-col {menuVisibleClass} bg-gray-700 px-4 py-2")">
  <NavLink class="" href="/">Home</NavLink>
  <NavLink class="" href="/counter">Counter</NavLink>
  <NavLink class="" href="/fetchdata">Fetch Data</NavLink>
</ul>
</div>

I’ve added an onclick event handler to the button. When it’s clicked ToggleMenu will be invoked.

The second part may look slightly over-complicated, but with good reason!

Rather than use a conditional @if to control visiblity of the menu I’ve opted to use CSS classes instead.

This is so we can override the class on larger screens (to permanently show the menu).

Here’s how it works:

First I’ve defined a string variable to store the value hidden if _menuVisible is false.

This will be used to hide the menu.

@{
  var menuVisibleClass = _menuVisible ? "" : "hidden";
}

I’ve then used a little string interpolation to include that class in the CSS class definition for our ul.

$"flex flex-col {menuVisibleClass} bg-gray-700 px-4 py-2"

To use C# when declaring values for an HTML attribute in Razor you can wrap the entire thing in brackets preceded by an @ symbol.
 class="@( $"border {blue}" )"
This makes it possible to declare C# in the value; In this example rendering the current value of blue as part of the CSS class attribute value.

Handle non-mobile

With that we’re almost done!

Now to make those links appear automatically (and the icon disappear) on larger screens.

We could just duplicate the ul and have a different one for larger resolutions, but this duplication is bound to catch us out when we come to add more links to the nav.

Instead, we can use some CSS trickery to re-use the exact same ul.

We’re aiming for the nav links to look like this on ‘medium’ and above resolutions.

Here’s how to break this down.

First, if we use flex for the outer div we can make the existing div (which includes the heading and hamburger icon) appear side-by-side with our ul nav links (on medium or higher screen resolutions).

<div class="bg-blue-500 text-white md:flex md:justify-between md:items-center">
<!-- existing content -->
</div>

But this looks a little, er, broken…

The links are still hidden
The hamburger icon is squashed up to the heading

The good news is, everything still looks right on mobile, but on larger resolutions we’re not quite there yet.

We don’t actually need to see the hamburger icon at this resolution so we can hide that with a simple md:hidden.

<button @onclick="ToggleMenu" class="md:hidden">
  <!-- button svg -->
</button>

We can also make our ul visible with a couple of flex classes.

<ul class="@($"flex flex-col {menuVisibleClass} bg-gray-700 px-4 py-2 md:flex md:flex-row")">
  <!-- links -->
</ul>

md:flex md:flex-row take care of making our links visible and displayed horizontally in a row.

Almost there! Now to make the ul background colour disappear on medium screens and above.

md:bg-transparent should do it.

<ul class="@($"flex flex-col {menuVisibleClass} bg-gray-700 px-4 py-2 md:flex md:flex-row md:bg-transparent")">
  <!-- links -->
</ul>

That’s a wrap!

There it is! We have a fully responsive nav bar with a teeny tiny bit of C# to make everything tick.

flex carries a bit of a learning curve, but Tailwind makes it easier to pick up and use.

Once you get the basics (mainly whether to use flex-row or flex-col and justifying items) there’ll be no stopping you!

The ability to to target common device resolutions using the breakpoint name as a prefix (md: in the examples above) makes it straightforward to employ different styles at different breakpoints.

Blazor has a small, but very useful role, to handle the click events for the ‘hamburger’ icon, translating that into a simple boolean to determine whether the menu should be visible or not (on smaller screens).

Next Steps

There are of course many more tweaks we could make from here. Here are a couple of ideas:

Make the links change appearance when you hover over them using Tailwind’s hover: pseudo class prefix
Use a second icon for when the nav links are visible on mobile, maybe an x to hide them again

Blazor by Example - Build a simple markdown editor

Jon Hilton — Mon, 27 Jan 2020 00:00:00 +0000

Blazor promises to empower C# developers to build modern web applications quickly, using a language and ecosystem they already know and understand.

So let’s see how this stacks up with a real-world requirement; building a simple markdown editor.

It’s hard to imagine a world without Markdown these days.

For everything from blog posts, to github issues and self published ebooks, Markdown has cemented its position has a convenient way to edit plain text, whilst maintaining some control over the ultimate format and appearance of your work.

Today’s Blazor example centres on building a markdown text editor.

The requirement is to provide a text box which accepts markdown and generates a live preview of the resulting HTML.

Here’s how I’d approach building something like this in Blazor:

Create the basic HTML structure (rows, columns etc)
Add the essential HTML elements (textarea in this case)
Add bindings to make the textarea value sync with a field/property in the component
Implement code to convert the markdown to HTML
Render the HTML on screen

Create the initial structure and elements

Let’s start with some basic HTML structure….

Editor.razor

@page "/markdown"

<div class="row">
    <div class="col-6">
        Editor goes here
    </div>
    <div class="col-6">
        Preview goes here
    </div>
</div>

I’m sticking to Bootstrap here because my CSS kinda sucks…

This gives us a simple two column layout for our page; now to add a textarea

@page "/markdown"

<div class="row">
    <div class="col-6">
        <textarea class="form-control"></textarea>
    </div>
    <div class="col-6">
        Preview goes here
    </div>
</div>

Run this and you’ll see a text area, nothing very interesting going on yet…

Bind your inputs to something

Now we’re ready to take the next step; we need to take whatever is entered into the textarea and store it in our component’s state.

For this, we can use properties and Blazor’s binding syntax. We just need to declare a couple of attributes:

<textarea class="form-control" @bind-value="Body" @bind-value:event="oninput">
</textarea>

These attributes tell Blazor to bind the value of textarea to a property called Body and to update Body whenever the value of our textarea changes.

The result? Body will always reflects the contents of the textarea. Whenever the value of textarea changes, Body will be instantly updated with the new value.

Now you might have noticed we haven’t created a Body property anywhere yet.

Whilst it is possible to write all your Blazor UI logic in @code blocks in the razor files themselves, I generally prefer to put that code into a separate class.

Let’s create a component base class for our component and declare the Body property in there:

Editor.razor.cs

using Microsoft.AspNetCore.Components;

public class MarkdownEditorBase : ComponentBase
{
    public string Body { get; set; }
}

Now we just need to update our component markup to inherit this component base class and, whilst we’re here, add a binding to render the current value of Body.

This way we can check that ‘Body’ definitely does update as we change the contents of the textarea.

@page "/markdown"
@inherits MarkdownEditorBase

<div class="row">
    <div class="col-6">
        <textarea class="form-control" 
            @bind-value="Body" 
            @bind-value:event="oninput">
        </textarea>
    </div>
    <div class="col-6">
        @Body
    </div>
</div>

Run this, type something into the textarea and you’ll see an instant preview of what you typed.

But, hold the phone, I promised an all-singing and dancing HTML preview…

As it stands, if you throw markdown at this textarea you’re just going to see that markdown in the preview, exactly as you typed it…

From markup to HTML

Happily, we don’t need to expend much effort to get HTML from this markup, we can employ the excellent Markdig .NET Markdown processor to do it for us.

Bring in the NuGet package…

Install-Package Markdig

Markdig will take any text and process the Markdown for us, spitting HTML out the other end.

Let’s add a new Preview property to our component which will invoke Markdig every time we request its value.

using Markdig;
using Microsoft.AspNetCore.Components;

public class MarkdownEditorBase : ComponentBase
{
    public string Body { get; set; } = string.Empty;
    public string Preview => Markdown.ToHtml(Body);
}

I’ve also updated Body so it will always have an initial empty string value (rather than being null which would trip Markdig up).

Now we can update our component markup to render this preview instead of Body

<div class="col-6">
    <textarea class="form-control" 
        @bind-value="Body" 
        @bind-value:event="oninput"></textarea>
</div>
<div class="col-6">
    @Preview
</div>

Run this now and tada…

I mean, it’s HTML, but not the glorious preview we were hoping for.

Ideally we’d want to actually render the HTML and get a sense of how our content is shaping up; seeing the raw HTML itself isn’t much use.

Luckily Blazor has one more trick up its sleeve; rendering raw markup.

By default Blazor won’t just push this markup out for your browser to render; after all, if you blindly accept code you don’t own and run it in the browser, any number of bad things could happen!

But if you’re happy with the risks, you can force Blazor to spit this code out raw and let the Browser do as it pleases.

<div class="col-6">
    @((MarkupString) Preview)
</div>

Now we’re talking.

Type markdown in on the left, get HTML rendered on the right.

Summary

Sometimes as a developer you come up against a requirement which you expect to be complex (and take ages) to build, and every now and again it turns out to be easier than you thought.

In this case, building a simple markdown editor using Blazor turned out to be pretty straightforward.

Markdig does all the heavy lifting and a tiny amount of Blazor binding syntax handles the rest.

Check out the complete source code for this example here.

6 Blazor component libraries to speed up your development

Jon Hilton — Mon, 20 Jan 2020 00:00:00 +0000

.NET Developers have a long history with component libraries.

If you’re not familiar with the concept, these are collections of components you can drop into your application when you want a certain bit of UI functionality for your app.

If you’re thinking tables, accordians and toggle buttons, you’re on the right track.

But why do such things exist? Why would you want to use a third party component in favour of “rolling your own”?

I can think of a few reasons.

CSS

I work with a couple of developers who “get” CSS. They seem to have an innate ability to create beautiful looking web applications; bending the browser to their will with a couple of well crafted lines.

I, on the other hand, can easily lose hours to a “simple bit of CSS”, fighting the syntax every step of the way, labouring to slay the CSS beast only to find it works perfectly on my Chrome desktop but resembles an early Geocities page when I view it on a mobile!

If component libraries can “do CSS” for me, I’m in…

Rapid prototyping

Even if you might want (or need) to write your own UI components, starting with a library can be a real time saver when it comes to spinning up a prototype or V1 of an application.

If you can drop a grid into your application, complete with paging, sorting, filtering etc. vs spending hours/days building one yourself, it’s got to be tempting to go with the first option (not least so you can focus on your business logic and flow).

Battle tested

All the big component libraries also have the benefit of being pretty well battle-tested.

Once a company like Telerik has released a few iterations of a grid component you’d imagine it will have gone through a hefty amount of testing (both internally and by customers) so it’s pretty low risk to use it in your own application (and you’d expect it to be cross browser compatible which is a significant time saver).

Exploring Blazor’s component libaries

So, if those are some of the benefits, what are the component library options for Blazor (as we move inexorably towards an official Blazor WASM release)?

The following list is almost certainly incomplete so feel free to hit me up on Twitter (@jonhilt ) or leave a comment and point out everything I’ve missed!

Radzen Blazor Components

Site: https://razor.radzen.com/

Pricing: Free for commercial use

Server: Yes

WASM: Yes

Radzen Blazor Components is a free set of 40+ native Blazor UI controls.

It includes all the basic form controls you’d hope (Date Pickers etc) along with data grids and containers such as accordians and tabs.

It doesn’t handle data visualisation e.g. charts.

SyncFusion Blazor UI Components

Site: https://blazor.syncfusion.com/

Pricing: Free community license or $995 /developer 1st year

Server: Yes

WASM: Yes

There are a number of component libraries which, on the face of it, seem “expensive” and SyncFusion is one of them.

Admittedly, value is in the eye of the bolder, and $995 a year might be peanuts compared to the productivity gains you’ll make as a reasonable sized company with more than a handful of developers.

However, it also pays to read the small print, and in this case they offer a community license based on you matching conditions laid out here.

Namely that you’re an individual or company with less than $1 million USD in annual gross revenue and 5 or fewer developers.

In terms of the components themselves, they have a comprehensive collection including small components such as Date Pickers all the way up to rich text editors, word processors and file managers.

Various options for data visualization are also included (charts etc).

Telerik UI for Blazor

Site: https://www.telerik.com/blazor-ui

Pricing: $899/developer perpetual license

Server: Yes

WASM: Yes

Doesn’t boast quite so many components as SyncFusion, but has the basics covered with Date Pickers, Buttons, Grids etc.

Also includes various charts for data visualisation.

DevExpress Blazor Components

Site: https://www.devexpress.com/blazor/

Pricing: Free “for a limited time”

Server: Yes (I think) - couldn’t see this listed explicitly anywhere…

WASM: Yes (I think) - as above

DevExpress’s library is currently free. However, the big caveat here is in the wording which includes the sentence “for a limited time”, so it’s hard to know where they’ll go with pricing in the future.

In terms of the library itself, it includes essentials like Data Grids, Charts, and various Editors (date pickers etc).

Blazored libraries and components

Site: https://github.com/Blazored

Pricing: Free

Server: Yes

WASM: Yes (I think)

This is a collection of GitHub repositories including various components such as Modals, Text Editors, Toast popups etc.

It offers some useful time savers such as Typeahead to offer up auto complete suggestions as you type into a text input.

Chris Sainty is behind this (I thoroughly recommend his excellent Blazor blog) and the code is all open source (available on GitHub).

Blazorise

Site: https://blazorise.com/

Pricing: Free

Server: Yes

WASM: Yes

Built on frameworks such as Bootstrap, Bulma and Material, Blazorise offers a decent number of components ready for you to drop into your Blazor apps.

You can use any of the free provided CSS frameworks, leaving you free to stick with Bootstrap if that’s what you generally use, or look at the alternatives (Bulma or Material).

Again the basics are all there (Editors, Buttons, Grids etc) and they have a Chart component to boot.

Use Blazor in your existing ASP.NET Core 3.x application

Jon Hilton — Wed, 04 Dec 2019 00:00:00 +0000

Starting with ASP.NET Core 3.0, you can add Blazor components to your existing ASP.NET Core (MVC, Razor Pages) application.

This is a great way to test the ground with Blazor, without chucking everything you have in the bin and starting over!

Here’s how to do it using ASP.NET Core 3.1 (released December 3rd 2019).

In your existing ASP.NET Core 3 app, you’ll need to update ConfigureServices in startup.cs to add all the services required for Blazor Server.

services.AddServerSideBlazor();

Now you can add the MapBlazorHub call in Configure to register the Blazor Hub endpoint (which Blazor Server uses to communicate with the browser).

app.UseEndpoints(endpoints =>
{   
    endpoints.MapRazorPages(); // existing endpoints
    endpoints.MapBlazorHub();                
});

Almost there; at this point your ASP.NET Core application is ready to process and render Blazor components.

Now you just need to render one!

You can add a .razor component somewhere in your application (for now I just put mine in the Pages folder and called it HelloWorld.razor ).

@page "/Hello"

<h3>HelloWorld</h3>

Hello @Name

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

@code {
    public string Name { get; set; } = "Jon";

    protected async Task Toggle()
    {
        if (Name == "Jon")
        {
            Name = "Susan";
        }
        else
        {
            Name = "Jon";
        }
    }
}

Finally, you can take an existing page like Index.cshtml and add some code to render your component:

@page
@model IndexModel
@{
    ViewData["Title"] = "Home page";
}

<script src="~/_framework/blazor.server.js"></script>

<component type="typeof(HelloWorld)" render-mode="ServerPrerendered" />

First we’ve added a reference to blazor.server.js ; this is required for Blazor to communicate between the browser and your application. You’ll find this script is automatically made available by your ASP.NET Core application.

Then we’ve used the component tag helper (new in ASP.NET Core 3.1) to render the HelloWorld component.

If you’re using ASP.NET Core 3.0, you’ll need to use HTML.RenderComponentAsync instead:

@(await Html.RenderComponentAsync<HelloWorld>(RenderMode.ServerPrerendered))

Spin this up in the browser now and you’ll see your component, rendered in all its glory (in your Razor page!)

However, the Toggle button won’t work until we take one more step.

Add an _Imports.razor file to your Pages folder:

@using System.Net.Http
@using Microsoft.AspNetCore.Components.Forms
@using Microsoft.AspNetCore.Components.Routing
@using Microsoft.JSInterop
@using Microsoft.AspNetCore.Components.Web

With that, your application has everything it needs to support Razor components; the HelloWorld component renders, and clicking the button changes the Name and re-renders the markup accordingly.

Move the Blazor script to shared layout

Now this works, but we can improve things further.

Currently, a SignalR connection will be opened up every time you navigate to Index.cshtml.

This might be less than desirable, not least because you get a small flash of content appearing every time this connection is made.

So a better option is probably to put this in your application’s Layout page (assuming you have one).

Shared/_Layout.cshtml

<!-- other scripts -->

<script src="~/_framework/blazor.server.js"></script>

@RenderSection("Scripts", required: false) <!-- existing code -->
</body>

What is RenderMode?

In this example I used RenderMode.ServerPrerendered.

You might be wondering what this means.

Essentially, there are three ways to render Blazor components in a Razor View or Page.

Static

ASP.NET will render the component at the same time as the rest of the page and return static html to your browser.

Server

ASP.NET will render a marker for the component, and return that with the rest of the page, at which point Blazor (running in the browser) will open up its socket connection to the server, render the component and then update the DOM in the browser to display the component.

ServerPrerendered

A kind of “best of both worlds”.

ASP.NET will render and return the component’s markup with the rest of the page. Then it will act the same as Server mode whereby it will include a marker for the component and set up a Blazor connection.

Which RenderMode?

Each of these three options has trade-offs, but the main thing to watch out for is performance and how they work with Seach Engines.

With RenderMode.Static your page is rendered entirely, in one call to the server.

This means, if a search engine comes along and requests your page, it will get the entire thing back (including your component) and can index it accordingly.

You can see this for yourself in the browser; hit your page and notice how the component markup is returned as part of the page response (this is using Firefox Dev Tools)…

However, the component is essentially “non-interactive” at this point. So clicking the Toggle button won’t do anything at all.

With RenderMode.Server mode, the opposite is true.

Your component won’t be rendered in the initial response when you visit the page:

Instead, Blazor will kick in after your page is rendered and then render the component (via the socket connection it opens up with your server).

Now the Toggle button works, but search engines won’t “see” that component markup when they index the page.

Finally, RenderMode.ServerPrerendered does both.

You get the initial markup for the component in the initial page response, then Blazor kicks in and opens up its socket connection for further interactions with the component.

Next Steps

Adding Blazor to your existing ASP.NET Core 3 app turns out to be relatively straightforward; you can give Blazor a try, without affecting the rest of your application and see for yourself whether you find it a productive way to build your application’s user interface.

Your simplest next step might be to take some small part of your UI (like a table, list, or some other read-only component) and try building that as a Blazor component.

That way, you can quickly get a feel for how building components differs from building pages or views before moving on to more “interactive” components (using callbacks etc).

But, which flavor of ASP.NET?

Jon Hilton — Wed, 13 Nov 2019 00:00:00 +0000

Two developers walk into a bar…

Developer: Hey, I want to build a web application and I’m looking to use Microsoft technologies

Me: Great, you’ll want to explore ASP.NET then

Developer: Sounds good, how do I get started?

Me: Well, which “flavor” of ASP.NET do you want to use?

Developer: What do you mean?

Me: Well, there’s MVC or Razor Pages for server-side development, unless you fancy trying Blazor in which case you can use Blazor Server, or if you’re happy to go really cutting edge there’s always Blazor Client?

Developer: Um, OK, well which is best?

Me: um…

Developer: Oh, and I’ve heard a lot of people recommending React, is that an option?

Me: (to bartender) I think we’re going to need another drink…

Making sense of the options

This is a GREAT time to be a web developer using MS technologies, but (and it’s a big but) it sure is confusing when you’re just getting started and you’re pelted with so many choices…

They say knowledge is power, so let’s break these options down…

Server-side or Client

Before we get into specifics, we should consider the two broad categories these options fall into.

Either, your application will run on the server , where the server takes on the job of retrieving data from a database, applying business logic, mangling data and markup together before spewing the results out as HTML (for your browser to render).

Or, you’ll build a client-side application where all the presentation markup and logic runs in the browser (typically javascript).

With this model, the browser makes an initial request to load the application’s HTML, CSS and javascript, and to render the initial (home) page.

Thereafter, the client application makes calls to your server when it requires data, or to execute business logic on the backend. The server returns data (typically JSON) which your client-side application mangles together with markup and displays in the browser.

One way or another, your data and markup get mangled together, either on the server, or on the client (browser).

But then, there is another option (kinda),

I know, I did say there were two options but… Blazor Server sits somewhere between the two, with most of the work done on the server but an atypical approach to making requests and receiving responses. More on that shortly.

Before we get there, where do the various flavors of ASP.NET fit into this picture?

ASP.NET MVC (Server-side)

With MVC, all the grunt work is done on the server and the browser is given straightforward HTML to render.

The user attempts to navigate to a URL in the browser.

The browser pings this requests over to the server.

ASP.NET MVC takes over, forwards the request to the relevant controller.

With MVC you use Controllers and return Views with data, like this…

public class UserController {

    public IActionResult List(){
        var data = //some data from your database
        return View(data)
    }

}

At this point, ASP.NET MVC renders your Razor View (by convention, that would be List.cshtml in the above example), using the data its been given. It then generates standard HTML and returns this to the browser.

The browser then renders this HTML.

When your user clicks buttons etc, the browser makes a request to the server, which forwards it to an ASP.NET Controller, which re-renders and returns the entire view.

Rinse and Repeat.

ASP.NET Razor Pages (Server-side)

Razor Pages (not to be confused with Razor Views, which are used in MVC) also does all its User Interface (UI) rendering on the server and returns HTML to the browser.

At a high level, this looks just like MVC. The main difference is how you organise your presentation logic and markup.

With Razor Pages you create Pages and update the Page Model with your data, like this…

public class UserList : PageModel
{
    public List<User> Users { get; set; }

    public void OnGet()
    {
        var users = //some data from your database
        Users = users;
    }
}

Just like MVC, when your users click buttons etc, the browser makes a request to the server which re-renders and returns the entire page.

Check out MVC vs Razor Pages for a more detailed comparison of the two approaches.

Blazor Server (Server-side/Client-side hybrid)

Blazor server is the new kid in town, and does something surprising.

With Blazor, when you launch your application, it retrieves some initial HTML, CSS and javascript.

But then it pulls a rabbit out of a hat and does something none of the other options in this list do; it opens up a socket connection to your server.

Now, when your users interact with your application, instead of requesting entire pages from the server, Blazor forwards things like button clicks etc. to the server over this socket connection.

The server then has a look at what event occurred (for example which button was clicked), runs whatever code you’ve written to handle that event, figures out which parts of the UI have changed, and sends a small diff (outlining which elements have changed) over the socket connection, back to the browser.

The part of your Blazor application which runs in the browser then process this diff and updates the DOM elements accordingly.

So the bulk of the processing (retrieving data, mangling this together with markup) happens on the server, and small diffs are transmitted to the browser so it knows which parts of the user interface to update.

With Blazor, you write your User Interface as a series of components, which can be composed together to form your application.

@page "/users"

<h3>Users</h3>

@foreach (var user in _users)
{
    <User name="@user.Name"/>
}

@code {
    private List<User> _users;

    protected override async Task OnInitializedAsync()
    {
        _users = //some data from your database
    }
}

Blazor WebAssembly (Client-side)

Blazor WebAssembly is still in preview but takes the Blazor story one step further.

With this, when your user visits your application, the entire Blazor application is sent to the browser as compiled C# DLLs. A compact version of the .NET runtime is also shipped to the browser.

Something called Web Assembly (which is baked into all modern browsers) bootstraps the .NET runtime and loads your assemblies (remember, all of this is happening in the browser).

Thereafter, the Blazor WebAssembly runtime handles things like DOM updates and sending API calls to your server.

In this mode, all your presentation logic actually executes in the browser, so button clicks and your handling code are executed and the UI updated in your browser, with no need to contact your server.

Well, until you need data.

Then, your Blazor WebAssembly application can make AJAX requests to your server, retrieve data (typically as JSON), mix this data up with your component markup (this is done in the browser) and render the resulting HTML.

People are excitied about this option because it opens the door to writing your web applications using C#, but still getting all the benefits of running a SPA (single page application) in the browser (performance, seamless showing and hiding of components etc.)

With Blazor WebAssembly, you write your User Interface using the exact same component model as Blazor Server; the main difference being how you retrieve data, via an AJAX call rather than a direct call to a service or some such…

@page "/users"

<h3>Users</h3>

@foreach (var user in _users)
{
    <User name="@user.Name"/>
}

@code {
    private User[] _users;

    protected override async Task OnInitializedAsync()
    {
        _users = await Http.GetJsonAsync<User[]>("users/list")
    }
}

Web API + JS SPA

Similar to Blazor WebAssembly, you can create a client-side web application using a JS framework like React, Angular or Vue.

Now when your user visits your application, an initial request is made to retrieve the application’s static HTML, CSS and javascript. This is loaded in the browser.

Thereafter, when your users interact with your application (clicking buttons etc) the javascript, running in the browser, can update the UI there and then (manipulating the DOM directly).

When the time comes to retrieve data from a backend, much like Blazor WebAssembly, you can make AJAX requests to your server, retrieve data as JSON then update the DOM to render this data.

Common ground

It’s tempting to look at these options and focus in on the differences, but it’s worth thinking about the common ground…

… they’re all meant for presentation, not business logic.

MVC, Razor Pages, Blazor and front-end frameworks such as React, Angular and Vue are all intended to help you build your user interface.

Their role is to render stuff in the browser, and handle “events” such as users clicking buttons, navigating to pages etc.

If you keep all your actual business logic elsewhere, then we’re talking about a relatively thin layer at the outer edges of your application; that bit where the users actually get to see and click things.

This is very good news! If you can build your business logic/data retrieval outside of this presentation code you’ll find it much easier to:

Build your user interface in the first place
Consider changing UI framework at a later date

And remember, whichever option you choose, you’re always free to change later.

The fundamental building blocks of all ASP.NET applications are the same (you’ll still be wiring up dependencies in startup.cs, adding DBContexts if you want to use EF Core etc.)

So choose freely, and remember you get to take everything you’ve learned with you (when you inevitably switch gears in 6 months time!)

There's a buzz about Blazor

Jon Hilton — Tue, 15 Oct 2019 00:00:00 +0000

Blazor has landed (albeit only officially supported in “Server” mode for now) and with it comes renewed optimism that javascript isn’t going to be the only front end game in town for the rest of eternity.

But can it, will it, should it ever replace Javascript?

If you’re currently committed to building Web APIs and applications using Vue/Angular/React are you destined to chuck everything in the bin and start all over again from zero?

Honestly? Probably not.

But, having seen the enthusiasm for Blazor at recent conferences and “out there” (the Internet, not aliens), I’m increasingly of the opinion that Blazor is a very good thing;

Here are three reasons why.

Alternatives are important

It’s tempting to assume that everyone has got over their objections to JS, embraced the ecosystem in its entirety and are now happily spinning round on their JS framework treadmill, churning out PWAs and SPAs to their heart’s content.

But, as one person succinctly outlined on /r/dotnet…

“I hate everything about javascript”

Who knows how this person really feels… but it’s fair to assume that some people have not jumped on the JS bandwagon and aren’t exactly happy about the prospect of doing so in the near future.

If you know C# and you’re comfortable operating within the .NET ecosystem, having a JS alternative which enables you to be productive, spin up “modern” web applications which are performant, using the tools you already know and love, sounds like a pretty good option to have up your sleeve.

Web Assembly isn’t just Microsoft

You’ve probably read about the two “modes” which Blazor can run in.

Blazor Server, available now, does all the heavy lifting on the server, transmitting a small amount of data up to the browser to tell it what to render in response to things happening within your application (button clicks etc.)

But Blazor Server is just the start. When Blazor WebAssembly drops next year, you’ll be able to deploy actual .NET DLLs to the browser.

Those DLLS will run on a version of the .NET runtime (in the browser) making it a fully-fledged SPA which happens to be written using C#.

This is enabled thanks to WebAssembly which is built into all modern browsers.

WebAssembly opens up the browser to run languages other then JS, and you can be sure Microsoft aren’t the only company exploring what this means and how they can best make use of it.

Chances are we’re going to see the browser move into areas it previously couldn’t, running more diverse applications as the technology matures and improves.

JS is still a big part of this picture, with WebAssembly able to call into and out of the JS context, but the options will be there to bring the tools and languages you already know to the party.

Shared models between browser and server is a BIG deal

If there’s one pain point which springs up again and again with full stack development it’s the problem of multiple versions of the same model.

With a typical JS based application you’re likely to end up with one version of your Model on the backend (strongly typed, in C# land) and then a completely separate representation of it in javascript (possibly typed if you’re using Typescript).

Keeping these in sync is a royal pain in the ass. It’s really only a matter of time before something changes on the back end causing a breaking change in the front end.

Code generation partially solves this problem, or at least removes the manual process otherwise required to keep the two in sync but still leaves you with two versions of the same model.

Blazor removes the problem entirely.

@inject HttpClient _httpClient

<h3>People</h3>

@foreach (var person in people)
{
    <h1>Hello @person.Name</h1>
}

@code {
    protected List<Person> people { get; set; } = new List<Person>();

    protected override async Task OnInitializedAsync(){
        await LoadPeople();
    }

    private async Task LoadPeople(){
        people = await _httpClient.GetJsonAsync<List<Person>>("http://yourapi.com/people");
    }
}

This is an example of Blazor Client (Web Assembly) using a model Person which is retrieved via an HTTP call to an API.

Just the ability to deserialise the API response into the Person model removes any realistic chance of breaking this application simply by making changes to its models.

(you also get intellisense, which is nice).

Starting out with the ASP.NET Core React template (part 3 - Separating out the frontend)

Jon Hilton — Wed, 18 Sep 2019 00:00:00 +0000

So now we know our way round the front end part of a new React + Web API project, and the Web API part.

But we left the last post on a bit of a cliffhanger.

We saw how you can choose to launch the React part of the application separately (running on its own port and not tied in with rebuilds of your C# API).

But, if you try this, launch the application and try to access the “Weather” page, you’ll just see the Loading… indicator and no actual data.

Broken URLs

So what’s going on?

Well, now the React frontend is running on localhost:3000, it’s phsyically separated from your ASP.NET Core Web API.

So, the code in FetchData.js is broken…

fetch('api/SampleData/WeatherForecasts')
    .then(response => response.json())
    .then(data => {
    this.setState({ forecasts: data, loading: false });
    });

Fetch is going to assume:

api/SampleData/WeatherForecasts

is located at:

http://localhost:3000/api/SampleData/WeatherForecasts

which is, of course, wrong.

What we actually want to do is hit our API server running on another port (40512 in my case; check Properties/launchSettings.json to discover yours).

To fix this we could just manually include the correct address in the fetch call…

fetch('http://localhost:40512/api/SampleData/WeatherForecasts')
    .then(response => response.json())
    .then(data => {
    this.setState({ forecasts: data, loading: false });
    });

But we could be making a lot of these network calls and it’s not ideal to have to include that first part of the URL in every case (not least because we might change it at some point during development, and definitely when we go live).

A better way is to define that URL once and use it everywhere; something we can do quite easily using that .env file we added last time.

Currently it looks like this…

BROWSER=none

But we can add anything we like to it.

Let’s add our API URL…

BROWSER=none
REACT_APP_API_URL=http://localhost:40512

To be able to retrieve this value in our React (javascript) code it needs to be prefixed with REACT_APP. Now we can retrieve this code whenever we need it like so…

process.env.REACT_APP_API_URL

So, a little string interpolation later and we end up with this…

fetch(`${process.env.REACT_APP_API_URL}/api/SampleData/WeatherForecasts`)
    .then(response => response.json())
    .then(data => {
    this.setState({ forecasts: data, loading: false });
    });

Notice the “not quite apostrophe” in there, the backtick at the beginning and end of the url string?

That allows us to use javascript’s template literals to interpolate expressions in your strings.

So in this case we’ll get the value of REACT_APP_API_URL pre-pended to the rest of our string.

Changing the URL in production

So far so good but we probably don’t want to use localhost in production. To use different settings in different environments we can define more than one .env file.

So in this case, if we define an .env.development file and put our localhost URL in there, we can put the actual, production, API address in .env.

That way we should end up with the correct API urls for both development and prod.

.env

REACT_APP_API_URL=https://API.YourDomainHere.io

.env.development

REACT_APP_API_URL=http://localhost:40512

Watch out for CORS

The final thing you’ll probably run into when you run your app in production is CORS.

As soon as you have your frontend and API applications running on different URLs, CORS is likely to raise its head and demand your attention!

If you see an error indicating that a Cross-Origin request was blocked, chances are you’ve run into CORS.

CORS exists to stop random code running in the browser from making requests to your API, but it has a nasty habit of cropping up when you try and access your API from your own applications as well.

Happily, you can easily configure ASP.NET Core with a CORS policy which allows your application through to your API,

Check out this article for more details on CORS and my handy CORS code generator to get the code you need to fix the problem.

Starting out with the ASP.NET Core React template (part 2 - Web API)

Jon Hilton — Fri, 06 Sep 2019 00:00:00 +0000

So now we know our way round the front end part of a new React + Web API project, what about the Web API part?

Everything else in the new project (apart from the ClientApp folder) is there to make your Web API work.

First up we have the Controllers folder.

API controllers for your data

In the controllers folder you’ll find an example controller which returns some hard-coded data for your application.

[Route("api/[controller]")]
public class SampleDataController : Controller
{
    // other code omitted

    [HttpGet("[action]")]
    public IEnumerable<WeatherForecast> WeatherForecasts()
    {
        var rng = new Random();
        return Enumerable.Range(1, 5).Select(index => new WeatherForecast
        {
            DateFormatted = DateTime.Now.AddDays(index).ToString("d"),
            TemperatureC = rng.Next(-20, 55),
            Summary = Summaries[rng.Next(Summaries.Length)]
        });
    }

    // other code omitted  
}

At the top we have a Route attribute which means any requests to our application /api/SampleData will be routed here.

The WeatherForecasts method has its own HttpGet("[action]") attribute.

This tells ASP.NET Core’s routing engine to take any requests to /api/sampledata/WeatherForecasts and forward them to this method (our controller action).

The rest of the code in this method (and more code in the controller which I’ve omitted for brevity) simply generates some random “weather” data and returns it as an IEnumerable of WeatherForecast.

The shape of the returned data is defined by the WeatherForecast type which looks like this…

public class WeatherForecast
{
    public string DateFormatted { get; set; }
    public int TemperatureC { get; set; }
    public string Summary { get; set; }

    public int TemperatureF
    {
        get { return 32 + (int) (TemperatureC / 0.5556); }
    }
}

Testing your work

To test a simple GET like this you can launch your application and click through the various screens in your front end app, or you can take a more direct approach and make HTTP requests direct to your API.

Start by launching your application.

If this is the first time you’ve launched you may run into a warning message about a “Potential Security Risk Ahead”; this is because ASP.NET is attempting to run using HTTPS but uses a special “self-signed” development certificate to make it work.

You wouldn’t want to use that certificate for deployment to production but it’s fine to accept this certificate and continue on your local machine. Here’s what the warning looks like in Firefox.

Once it’s up and runnning, you can test that GET action by simply entering the URL in the browser…

Alternatively you can use other tools to test your API.

Postman and Insomnia are the two major contenders for this job, with my personal favourite being Insomnia.

To test your API using Insomnia you need to download and install it, then take note of the address your application is running on, and enter it into the URL box at the top of the screen.

Ensure the request type is GET, hit Send and you should see your lovely random weather data returned.

Startup.cs

The other file of note in the backend part of the project is startup.cs.

In ASP.NET Core this is where you’ll find yourself configuring your application.

Take a look and you’ll see various calls to tell ASP.NET how it should operate.

For example, the following code tells ASP.NET Core to show a “developer friendly” error message if we’re running in development mode (on a development machine)…

if (env.IsDevelopment())
{
    app.UseDeveloperExceptionPage();
}

Most of this file is bog standard ASP.NET Core but there are a few React/SPA specific calls.

Most notably you’ll see a call to UseSpaStaticFiles.

When you run your application in production your React code will be compiled and minified into static .html and .js files in ClientApp/build.

UseSpaStaticFiles and the corresponding call to AddSpaStaticFiles ensure these compiled and minified files will be served to the browser when a user visits your application.

UseSpa similarly ensures that the default starting page for your React application is served up when requests are made to the application.

This code…

if (env.IsDevelopment())
{
    spa.UseReactDevelopmentServer(npmScript: "start");
}

… makes sure that your React application is served using the React Development server when running in Development mode (on your machine).

This gives you more detailed output in the console of the browser and also handles things like auto-refreshing the browser when you make changes to your application.

Launch and/or publish your application

It’s worth knowing what’s going on when you launch or publish your application.

If you take a gander at your application’s .csproj file you’ll notice some calls to npm.

<Target Name="PublishRunWebpack" AfterTargets="ComputeFilesToPublish">
        <!-- As part of publishing, ensure the JS resources are freshly built in production mode -->
        <Exec WorkingDirectory="$(SpaRoot)" Command="npm install"/>
        <Exec WorkingDirectory="$(SpaRoot)" Command="npm run build"/>

        <!-- rest of code omitted for brevity -->
</Target>

When you publish your application these npm calls ensure any front-end dependencies are downloaded and that your application is built (compiled and minified) ready to be served in production.

To run your project locally you can just hit CTRL+F5 (in VS) and both parts of the application (front-end and back-end) will be launched together, running at the same web address.

You can control which port is used by modifying the launchSettings.json file in the Properties folder.

So in this example, if you launched this application using IIS Express it would run on port 40512 (http) or 44360 (https).

"iisSettings": {
    "windowsAuthentication": false,
    "anonymousAuthentication": true,
    "iisExpress": {
      "applicationUrl": "http://localhost:40512",
      "sslPort": 44360
    }
  },

Launching the React application on its own URL

One downside to running both the React and ASP.NET Core parts of your application together is that any changes to your C# code will trigger a recompile and restart of your application, rendering your React front-end unresponsive for a few seconds.

The ASP.NET Core build will also take longer because it also has to rebuild the React part of the application, even if you haven’t changed it.

To work around this you can choose to launch the React part of the application separately, on its own port.

To do so, add a .env file to the ClientApp directory and add this setting:

BROWSER=none

Now you’ll need to launch the React application manually (it won’t launch when you launch the .net application):

cd ClientApp
npm start

By default your React app will launch on port 3000.

Now you need to alert ASP.NET Core to this fact by making a small change to startup.cs.

Replace spa.UseReactDevelopmentServer with this code:

spa.UseProxyToSpaDevelopmentServer("http://localhost:3000");

Now when you build and launch your ASP.NET Core app it won’t launch its own React server or restart the one you’ve manually started.

You’ll find your application running at http://localhost:3000 whilst your ASP.NET Core API continues to run on the port specified in launchSettings.json.

There are a few gotchas to watch out for if you go down this route: specifically you might find your network requests to the API start failing; my next post will explain why (and how to fix it).

Starting out with the ASP.NET Core React template

Jon Hilton — Wed, 03 Jul 2019 00:00:00 +0000

Agghhh, what’s with all those files when you spin up a new ASP.NET Core and React.js project?!

The “out of the box” experience if you’re new to either React or ASP.NET Core (or both) can be pretty overwhelming; it’s hard to know where to start.

So let’s break it down and see what we’ve got.

First up it’s fairly straightforward to spin up a new project which gives you both React and ASP.NET Core …

Using the dotnet CLI…

dotnet new react

Or Visual Studio/Rider etc.

Either way you’ll end up with something which looks like this…

Now at first glance there may seem to be a lot going on here (especially when you start drilling into the various folders) so let’s break it down.

The project is best considered as two entirely separate entities which happen to be co-located in the same place.

A React application (using “Create React app”)
An ASP.NET Core Web API backend

React front end

ClientApp houses the frontend part of your new application.

So long as you’re using version 2.1 or higher of the .NET SDK you’ll find this part of the application is a standard React application created using something called “Create React App”.

The only real difference between this and a CRA app is that the .NET team have also provided some example React components to help get you started.

When you run the application ClientApp/public/index.html will be served to your browser.

In there you’ll see a div which looks like this…

<div id="root"></div>

This element is all important as React will render your application into this div.

Take a look at ClientApp/src and you’ll see some .js files and a components folder.

In index.js you’ll see the very “top” of your application; this is where it all starts.

import 'bootstrap/dist/css/bootstrap.css';
import React from 'react';
import ReactDOM from 'react-dom';
import { BrowserRouter } from 'react-router-dom';
import App from './App';
import registerServiceWorker from './registerServiceWorker';

const baseUrl = document.getElementsByTagName('base')[0].getAttribute('href');
const rootElement = document.getElementById('root');

ReactDOM.render(
  <BrowserRouter basename={baseUrl}>
    <App />
  </BrowserRouter>,
  rootElement);

registerServiceWorker();

The first few lines bring in various modules from other js files and node modules you need to run the app.

Then a variable is declared which points to that div we noticed earlier in index.html (with id root).

ReactDOM is called to render your application which consists of a BrowserRouter and App components into this root div.

So far so good.

Now if you head into the <App /> component you’ll see yet more of that funny looking “almost HTML” which points to yet more components…

export default class App extends Component {
  static displayName = App.name;

  render () {
    return (
      <Layout>
        <Route exact path='/' component={Home} />
        <Route path='/counter' component={Counter} />
        <Route path='/fetch-data' component={FetchData} />
      </Layout>
    );
  }
}

That “almost HTML” is actually “JSX”. It may look like HTML but is actually converted into javascript which React then uses to interact with the DOM in your browser.

This React component (App) nests a few Route components inside a Layout component.

Already we’re beginning to see how React apps are built as lots of small components which can be composed together.

In this case, Layout takes care of rendering things like a NavBar for the application then these Route components let you assign paths to specific components.

So when you run the app in a browser and head over to /fetch-data the FetchData component will be rendered but if you head to /Counter then FetchData will be omitted from the DOM and you’ll get the Counter component being shown instead.

Because the Layout component is rendered by itself (not using a Route component) it will remain visible all the time (irrespective of the path you navigate to).

Next Steps

The best way to figure out how the template works is to explore further and try to break some things!

When you run the application (from VS or the CLI) you’ll find the React app launches in your browser.

As you click on the links in the NavBar you’ll see how the general Layout (including NavBar) remain the same but the rest of the page updates to show the relevant component(s).

From here on, any changes you make to the front end part of your application will trigger an update in your browser, so you can quickly change/tweak and generally fiddle with stuff and immediately see the results of your efforts!

Next time we’ll take a quick tour of the Web API part of the project.

WTF is an Action Delegate?

Jon Hilton — Fri, 22 Mar 2019 11:13:26 +0000

In the last post we explored what a lambda is, and what that weird x=>x syntax is all about.

Now we know what it is, you might be wondering where can you use them and how might you write your own code so that a lambda can be used.

The answer is delegates!

Delegates act as a kind of placeholder for a method.

Let's take an example.

static void SaveToDatabase(Person person)
{
    try
    {
        // save here
    }
    catch (Exception)
    {
        Console.WriteLine("could not save");
    }
}

This method theoretically saves a person object. If something goes wrong, we catch the exception and log an error message to the console.

Plug 'n' Play behaviour

Now imagine we're going to call this SaveToDatabase method from various places and want to be able to change how we log this message on a case by case basis.

For example, instead of writing to console, sometimes we might choose to send an email instead.

One way to tackle this would be to make it possible for SaveToDatabase to take in a method which does the actual error logging. Then we can choose whether to pass in a method which writes to the console or a method which sends an email.

static void SaveToDatabase(Person person, Action onError)
{
    try
    {
        // save here
    }
    catch (Exception)
    {
        onError();
    }
}

SaveToDatabase now indicates that it expects to receive a method (onError).

The Action type here defines our onError argument as a delegate which takes zero arguments and doesn't return anything.

At this point SaveToDatabase doesn't know anything about what onError does, it merely knows its shape (a method with no arguments which returns void) and can "invoke" it whenever it likes, using this syntax...

onError();

This frees us up to pass in different methods when we call SaveToDatabase.

![](https://jonhilton.net/img/2019-02-07-what-are-action-func-delegates/2019-02-08-12-40-16.png)

Like so...

static void Main(string[] args)
{
    var person = new Person { Name = "bob" };
    SaveToDatabase(person, WriteErrorToConsole);
}

private static void WriteErrorToConsole()
{
    Console.WriteLine("Could not save");
}

Here we've created a method which takes no arguments and returns void (fulfilling the requirements for onError) and passed a reference to it along to SaveToDatabase.

Note we're not invoking WriteErrorToConsole in the Main method.

At no point do we do this...

WriteErrorToConsole()

Because that would immediately invoke the method and write a message to the console.

What we want is to pass that method along to SaveToDatabase which will invoke the method at a time of its own choosing.

Remember in the last post we discovered we can take a method like WriteErrorToConsole and "inline" it using lambdas?

We can do something very similar here...

static void Main(string[] args)
{
    var person = new Person { Name = "bob" };
    SaveToDatabase(person, ()=> Console.WriteLine("Could not save"));
}

We can't use x=>x because onError doesn't expect any arguments. Instead, we use empty parenthesis which serve the same purpose, but for Actions which take zero arguments.

I want to say something else

What if we don't want to write "Could not save" to the console, but provide a more specific message (which varies depending on the actual error)?

For this we need to make our onError action accept some kind of error message...

catch (Exception ex)
{
    onError(ex.Message);
}

Whichever method gets passed in (the one which sends an email, or the one which writes to console) could make use of this message string and do with it as it pleases.

To make this work we need to tweak our declaration of the onError Action slightly.

static void SaveToDatabase(Person person, Action<string> onError)
{
    try
    {
        // save here
    }
    catch (Exception ex)
    {
        onError(ex.Message);
    }
}

Now we're using Action<string> which means we're expecting a method which takes a single string argument and returns void.

Our Main method can take that argument and use it when writing to the console.

static void Main(string[] args)
{
    var person = new Person { Name = "bob" };
    SaveToDatabase(person,
        message => Console.WriteLine($"Could not save, error: {message}"));
}

Delegates delegates everywhere

As you've seen, delegates are pretty powerful and can be a great way to use the same function to do slightly different things depending on what delegate you pass in.

Here we've stuck to Action delegates but you can also use something called a Func.

WTF Is a Lambda?

Jon Hilton — Thu, 07 Mar 2019 14:01:07 +0000

If you're just learning C# you've probably come across something like this and wondered what the weird x=>x is all about...

things.SingleOrDefault(x=>x.Name == "Bob");

To understand what's going on, let's explore a specific example.

Let's say you have a collection of People.

Here's a class to represent a Person...

public class Person
{
    public string Name { get; set; }
    public int Age { get; set; }
}

Then somewhere in your application, a list of people like this...

private List<Person> People = new List<Person>
{
    new Person { Name = "Bob", Age = 37 },
    new Person { Name = "Brian", Age = 21 },
    new Person { Name = "Amy", Age = 58 }
};

Three people in a list. Each object in the list is an instance of our
Person class.

Now say you want to find the record for "Amy" and display her age.

You could do this manually by looping through each person until you find
the relevant one...

public void Exists()
{
    Person result = null;

    foreach (var person in People)
    {
        if (person.Name == "Amy")
        {
            result = person;
            break;
        }
    }

    if (result != null)
        Console.WriteLine("we found Amy!, she's " + result.Age);
}

Result will be the instance of "Person" for Amy and we can write her age to
the console.

Alternatively, rather than typing out endless loops yourself, you can use
some methods built in to C# lists to save yourself a few keystrokes.

public void Exists()
{
    var amy = People.SingleOrDefault(IsAmy);
}

Under the covers, this will loop through the "People" list, and for each
one it will call IsAmy to determine whether this is the person we want.

What does IsAmy look like I hear you ask.

private bool IsAmy(Person arg)
{
    return arg.Name == "Amy";
}

SingleOrDefault expects a function, which takes a Person and returns a bool.

In here we can put whatever logic we want.

If IsAmy returns true, then we're saying this instance of Person is the
one we want. If we return false we're saying it isn't.

We can "inline" our IsAmy function (to save declaring it separately) like
so...

public void Exists()
{
    var amy = People.SingleOrDefault((Person person) => 
                                        { return person.Name == "Amy" });
}

This is exactly the same as the last example, except instead of declaring a
separate function we're declaring it "inline".

You can see we're still taking in a Person argument, then returning a
true or false (true if "Amy", false if not).

Finally, to make this more concise, we can simplify to this...

public void Exists()
{
    var amy = People.SingleOrDefault(person => person.Name == "Amy");
}

This is another way of declaring the same thing.

Here, we are still taking the Person, applying our condition to it and
returning the result (true or false) but with less keystrokes!

So the left side of the => is the argument (Person), the right side is the
expression which returns a boolean.

Essentially lambdas are really just syntactic sugar and a shorthand way of
declaring a function.

You'll see them used a lot with lists/other collections and therefore in
relation to database queries etc.