Implement PageService for programmatic page title and meta tag management (Page.Title, MetaDescription, MetaKeywords)

[Copilot]

ASP.NET Web Forms applications rely on Page.Title, Page.MetaDescription, and Page.MetaKeywords for programmatic page metadata updates. Blazor's <PageTitle> and <HeadContent> components only support declarative markup, blocking migration scenarios where metadata is set dynamically in code.

Changes

Core Implementation

• IPageService/PageService: Scoped service with Title, MetaDescription, and MetaKeywords properties
• Event notifications: TitleChanged, MetaDescriptionChanged, MetaKeywordsChanged
• Page component: Subscribes to all property changes, renders dynamic <PageTitle> and meta tags via <HeadContent> with safe cross-thread updates
• Auto-registered via existing AddBlazorWebFormsComponents() extension

Testing & Samples

• 17 unit tests covering service behavior, component rendering, events, and DI
• Interactive sample at /UtilityFeatures/PageService with inputs for all three properties and navigation integration
• All 512 tests passing (476 original + 36 from recent merges)

Documentation

• Complete migration guide at docs/UtilityFeatures/PageService.md
• SEO best practices and usage examples
• Added to mkdocs.yml nav and README.md

Usage

@page "/customers/{id:int}"
@inject IPageService PageService

<Page />

@code {
    protected override async Task OnInitializedAsync()
    {
        var customer = await GetCustomer(Id);
        PageService.Title = $"Customer: {customer.Name}";
        PageService.MetaDescription = $"View details for {customer.Name}";
        PageService.MetaKeywords = "customer, crm, details";
    }
}

Migration Path

// Web Forms (.NET 4.0+)
Page.Title = "Dynamic Title";
Page.MetaDescription = "Description for SEO";
Page.MetaKeywords = "keyword1, keyword2, keyword3";

// Blazor
PageService.Title = "Dynamic Title";
PageService.MetaDescription = "Description for SEO";
PageService.MetaKeywords = "keyword1, keyword2, keyword3";

Screenshots

Sample application demonstrating all three properties with dynamic updates:

Web Forms Compatibility

Provides full API parity with ASP.NET Web Forms Page object properties introduced in .NET 4.0, enabling seamless migration of code that programmatically sets page metadata for SEO and browser display.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Need a BasePage to provide some of the base services</issue_title>
<issue_description>There are several features in the Page object that should be made available to the application.

• Page.Title</issue_description>

<agent_instructions>I need some research and ideas around this. I think the Page object may need to be some shared state that all of the components and blazor page elements are able to reference</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@csharpfritz Some initial research done in the spike_UserControl branch @csharpfritz Not entirely sure... needs some more research and discussion. This could be a key-piece to allow complete site-migration.

Adding to the parking lot for investigation after components are completed</comment_new>

• Fixes Need a BasePage to provide some of the base services #100

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[csharpfritz]

@copilot there are other features from WebForms that are provided in the Page attribute of components that we should be able to support. Review the old WebFOrms documentation, evaluate what additional properties would be desired on the PageService and implement those

To fix the problem, we should remove the unused local variable while preserving the Render(@<Page />); call so that the component still renders and the pageService interactions occur. In general, when a variable is only used to store the result of a method call whose return value is never read, you should either remove the variable and call the method for its side effects only, or remove the call entirely if its side effects are not needed.

For this specific case in src/BlazorWebFormsComponents.Test/PageService/ComponentTests.razor, in the Page_ComponentWithTitle_ServiceHasCorrectTitle test method, replace var cut = Render(@<Page />); with just Render(@<Page />);. No imports, method definitions, or other changes are required. The first and third tests remain unchanged. Functionality is preserved: the page still renders and can update pageService.Title, and the test still asserts on pageService.Title.

In general, to fix a “useless assignment to local variable” you either remove the unused variable and assignment entirely, or, if you need the right-hand side expression for its side effects, you keep just the expression (or assign it to _/a discard) without introducing an unused named local.

Here, var title = PageService.Title; is only verifying that PageService.Title can be accessed. The value is not used anywhere else. The minimal, behavior-preserving fix is to access the property without assigning it to a local, e.g. var _ = PageService.Title; or simply PageService.Title;. In tests, using a discard variable communicates intent clearly. We will therefore change line 25 in src/BlazorWebFormsComponents.Test/PageService/InjectionTests.razor to use a discard variable instead of the unused title. No new imports, methods, or other definitions are required.

---

Generally, the fix is to avoid a blanket catch (Exception) and instead either (1) catch only specific, expected exception types, or (2) if a broad catch is truly required, handle expected exceptions and log or rethrow unexpected ones instead of silently swallowing them. This preserves diagnosability while still preventing non-critical failures from crashing the component.

In this specific method, we want to keep the behavior that exceptions during title update do not break the component lifecycle, but we should not silently ignore every failure. The simplest, non‑breaking change is to catch Exception into a variable, log it using a standard logging mechanism (ILogger<Page>), and still prevent the exception from propagating. This keeps runtime behavior (no thrown exception from here) but improves transparency and addresses the “generic catch clause” concern by making it explicit that we are intentionally handling all exceptions and persisting details. Since we cannot modify other files, we’ll inject ILogger<Page> into this component and use it in the catch block. The steps in src/BlazorWebFormsComponents/Page.razor.cs are:

• Add a using Microsoft.Extensions.Logging; at the top (well-known library).
• Add an [Inject] private ILogger<Page> Logger { get; set; } = null!; property to the component.
• Change catch (Exception) to catch (Exception ex) and log the exception via Logger.LogError(ex, "...") instead of leaving the catch block empty.

This keeps existing functionality (no visible behavior change for callers) while making unexpected exceptions visible and intentional.

[Copilot]

@copilot there are other features from WebForms that are provided in the Page attribute of components that we should be able to support. Review the old WebFOrms documentation, evaluate what additiona...

Added MetaDescription and MetaKeywords properties to PageService, providing complete parity with ASP.NET Web Forms Page object (.NET 4.0+) for SEO meta tag management. Implemented in commit fafdb57.

Properties Added:

• PageService.MetaDescription - Equivalent to Page.MetaDescription
• PageService.MetaKeywords - Equivalent to Page.MetaKeywords
• Both include change events and reactive updates via the Page component

Testing: 8 new unit tests added, all 512 repository tests passing.

Sample Updated: Demo now shows all three properties (Title, MetaDescription, MetaKeywords) with working inputs and Web Forms comparison.

Screenshot: https://github.com/user-attachments/assets/b2b1e22d-cba6-4b4f-95c3-788db35a4f12