In previous articles, we have created a solution which contains an API project and a Blazor WebAssembly Standalone App. We also have demonstrated how the API can be called from the Blazor WebAssembly project.

Now, then plan is to extend that application and add some components. Some components for providing UI for add student functionality. But for adding new UI pages, we should understand how the navigation works in the Blazor.

So, in this article, we are going to talk about some basics about routing and navigation in the Balzor applications.

App.Razor

Every Blazor WebAssembly Application has an App.razor page. This component is basically the root component of the application. It sets up the client-side routing using the Router component.

The Router component intercepts browser navigation and renders the page that matches the requested address. The default code in this page is shown below.

Here, there are two child elements, Found and NotFound. Found element is called, when the incoming request’s route matches a component. If it matches, then the route data is passed to the component. It also decides the layout to be used.

The NotFound element can be used for adding custom content for a non-existing path. If the incoming request has a path which does not match with any existing route, then the NotFound element is invoked and the custom data from that element is rendered.

AppAssembly is another interesting thing in the above code. It can get or set the assembly that should be searched for components matching the URI.

The Found element has two children:

• RouteView , which passes route data and provides default layout.
• And the other child is FocusOnNavigate. Use the FocusOnNavigate component to set the UI focus to an element based on a CSS selector after navigating from one page to another.

In the code given above, you can see the FocusOnNavigate component in use by the App component of an app generated from a Blazor project template. This configuration suggests that as soon as page is loaded, the focus should be on the h1 element which is defined within that page.

Now, we have enough information about the code which is present in this file.

The @page Directive

Most of us may have used ASP .NET Core Web App ( or Web API) projects which has controllers. In those projects, the route of any action is inferred based on location of controller (e.g. {area}/{controller}/{action}).

This is where Blazor web applications differ from those applications. A Blazor component must have a @page attribute specified in the component. This directive takes a string parameter – which is route template, specifying the route which matches to that component.

For example, if a component has code @page '/counter', it will be served if the incoming request is https://{hostname}/counter URL.

The route template can also have additional things like route parameters and constraints on those route parameters can also be specified, if needed. When a Razor component (.razor) with an @page directive is compiled, the generated component class is provided a RouteAttribute specifying the component’s route template.

So, we now know which code is responsible for routing. But how does it really works ?

How does it work ?

When an application starts, the assemblies specified in AppAssembly attribute is scanned to gather all the RouteAttributes specified in all the components.

At runtime, the Router component intercepts the requests. If the coming request’s route matches with any existing component, then Found component is invoked. Inside Found component there is a  RouteView component. It receives the RouteData from the Router along with any route parameters. After that, it renders the specified component with its layout, including any further nested layouts.

That’s it for today’s short post ! In the next article, we will try to create a new page and we will also set appropriate routing for that component.

I hope you find this information helpful. Let me know your thoughts.