Routing and Layouts

Routes in Blazor come from the components themselves. A component with a @page directive claims an address, and the router builds its table by scanning the assembly at startup. There is no route file to keep in step with the pages.

A layout is the other half of the same subject. It is a component with a hole in it: the shared header, navigation and footer, with the routed page rendered in the middle. Every page gets one without asking, and a page can opt out when it needs to.

@page "/employees/{Id:int}"
@page "/employees/{Id:int}/{Tab}"
@rendermode InteractiveServer
@inject EmployeeService Employees
@inject NavigationManager Navigation

<h1>@(employee?.Name ?? "Employee")</h1>

@if (employee is null)
{
    <p role="status">No employee has id @Id.</p>
}
else
{
    <p>@employee.Department, started @employee.StartDate.ToString("d MMM yyyy")</p>
    <p>Section: @(Tab ?? "details")</p>

    <button type="button" @onclick="BackToList">Back to the list</button>
}

@code {
    [Parameter]
    public int Id { get; set; }

    [Parameter]
    public string? Tab { get; set; }

    private Employee? employee;

    protected override void OnParametersSet()
    {
        employee = Employees.Find(Id);
    }

    private void BackToList() => Navigation.NavigateTo("/employees");
}

• @page is the route, and it must begin with a slash. Request /employees/42 and the router renders this component.
• Two @page directives on one component are allowed. Both addresses render this page; the second supplies a Tab value and the first leaves it null.
• {Id:int} is a route parameter with a constraint. /employees/abc does not match this route at all, so you never parse a segment that was never a number.
• A route parameter is matched to a [Parameter] property by name, ignoring case. Spell them differently and the property keeps its default value, which shows up as a page about employee zero.
• @inject asks for a service registered in Program.cs. Dependency injection has its own lesson later; NavigationManager is the exception worth knowing now, because the framework provides it without any registration of yours.
• OnParametersSet runs whenever the parameters have been set, including when only the route changed. Loading in OnInitialized instead would miss a move from /employees/42 to /employees/43, because the component is reused and never initialises again.
• NavigateTo changes the address and renders the matching component, without a full page load.

@inject NavigationManager Navigation

@code {
    [SupplyParameterFromQuery]
    public string? Department { get; set; }

    [SupplyParameterFromQuery(Name = "page")]
    public int? PageNumber { get; set; }

    private async Task Save(EmployeeEdit edit)
    {
        var saved = await Employees.SaveAsync(edit);
        Navigation.NavigateTo($"/employees/{saved.Id}");
    }

    private void FilterBy(string department)
    {
        Navigation.NavigateTo(
            Navigation.GetUriWithQueryParameter("department", department));
    }
}

• NavigationManager reports the current address and changes it. Injecting it needs no registration from you.
• NavigateTo with a relative path performs a client-side navigation: the router matches the new address and renders the page, with no full reload. Pass forceLoad when you genuinely need the server to serve the page again, and leave a comment saying why, because it is rare.
• SupplyParameterFromQuery reads a query string value into a property, and Name lets the property and the parameter differ. Filters, paging and sort order belong in the query string, because then the current view is an address someone can share and the back button behaves the way people expect.
• GetUriWithQueryParameter rebuilds the current address with one parameter changed, keeping the others. Concatenating query strings by hand is where duplicated parameters and lost filters come from.
• Navigating after a save is a choice, not a rule. Staying put with a clear confirmation is often kinder; if you do navigate, make sure the destination shows evidence that the save worked, rather than leaving the reader to assume.

@inherits LayoutComponentBase

<div class="portal">
    <header>
        <a class="skip-link" href="#main">Skip to main content</a>
        <span class="brand">Employee Portal</span>
    </header>

    <nav aria-label="Main">
        <NavLink href="/employees" Match="NavLinkMatch.Prefix">Employees</NavLink>
        <NavLink href="/reports" Match="NavLinkMatch.All">Reports</NavLink>
    </nav>

    <main id="main">
        @Body
    </main>

    <footer>Internal use only. Contact the IT service desk for access.</footer>
</div>

@* A page that should not show the navigation chrome *@
@page "/reports/print"
@layout PrintLayout

• @inherits LayoutComponentBase is what makes this component a layout. It supplies the Body property.
• @Body is the hole. The routed page renders there, and everything around it is shared by every page using this layout.
• The default layout is named once, on the RouteView in Routes.razor, so no page has to opt in.
• @layout on a page overrides that default. A print view, or a sign-in screen that should not offer navigation to people who cannot use it yet, are the usual reasons.
• Layouts nest: a layout can itself declare @layout, so a section of the portal can add a sub-navigation inside the main surroundings.
• Match="NavLinkMatch.Prefix" keeps the Employees link marked as current while you are on /employees/42. NavLinkMatch.All marks it only on an exact match, which is what a home link wants.
• The nav element has an accessible name, and the skip link lets a keyboard user pass navigation that repeats on every page. If your design signals the current page with colour, add aria-current to the active link as well — a CSS class carries no meaning to a screen reader.