Create article: Return Razor component HTML from a web API using RazorComponentResult

[Copilot]

Fixes #37371 (Thanks @bassem-mf! 🚀)

Dan ... This is a new article covering ...

• How to use RazorComponentResult<T> at Minimal API endpoints to render Razor components as static HTML strings.
• How to consume that HTML in a Blazor component via IHttpClientFactory + MarkupString.

New file: aspnetcore/blazor/components/return-component-html-from-a-web-api.md

Covers three areas:

• Defining Razor components (with and without [Parameter]) in the web API project
• Registering AddRazorComponents() and mapping endpoints using RazorComponentResult<T>, passing parameters via Dictionary<string, object?>
• Consuming the API from a Blazor component — named HttpClient setup, GetStringAsync, cast to MarkupString for rendering

Key note surfaced in the intro: components rendered this way are static HTML only — no SignalR, no interactivity.

app.MapGet("/hello", () => new RazorComponentResult<Greeting>());

app.MapGet("/user/{id:int}", (int id) =>
{
    var parameters = new Dictionary<string, object?> { { "UserId", id } };
    return new RazorComponentResult<UserData>(parameters);
});

Updated: aspnetcore/toc.yml

Added "Return a component from a web API" entry immediately after "Class libraries with static SSR".

• Fixes Create a new article on how to return HTML from Minimal API endpoints using RazorComponentResult #37404

---

Internal previews

File	Preview link
aspnetcore/blazor/components/return-component-html-from-a-web-api.md	aspnetcore/blazor/components/return-component-html-from-a-web-api
aspnetcore/toc.yml	aspnetcore/toc

[guardrex]

@copilot ... Apply the suggestions that I made to the PR.

[Copilot]

@copilot ... Apply the suggestions that I made to the PR.

Done. Both suggestions applied in bd25d80~... — the intro paragraph now includes the article overview sentence and uses RazorComponentResult%601 xref encoding, and the [Parameter] reference links to xref:Microsoft.AspNetCore.Components.ParameterAttribute.

[Copilot]

Pull request overview

Adds new Blazor Components documentation describing how to return Razor component HTML from Minimal API endpoints using RazorComponentResult<T> and how to consume/render that HTML from a Blazor component, and links the new article from the ASP.NET Core TOC.

Changes:

• Added a new article at aspnetcore/blazor/components/return-component-html-from-a-web-api.md with end-to-end guidance and samples.
• Updated aspnetcore/toc.yml to include a new entry under Blazor > Components.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
aspnetcore/blazor/components/return-component-html-from-a-web-api.md	New article explaining RazorComponentResult usage in Minimal APIs and rendering the returned HTML in Blazor.
aspnetcore/toc.yml	Adds the new article to the Blazor Components section of the TOC.

[guardrex]

@copilot ... I agree with both of the suggestions from your review. Apply those two suggestions to the PR.

[Copilot]

@copilot ... I agree with both of the suggestions from your review. Apply those two suggestions to the PR.

Both suggestions applied in the latest commit:

1. Lines 15–17: Switched to the non-generic <xref:Microsoft.AspNetCore.Http.HttpResults.RazorComponentResult> xref (dropped the %601 generic suffix).
2. Lines 78–79: Changed "create an IHttpClientFactory" → "inject IHttpClientFactory", and added the standard [!WARNING] about rendering untrusted HTML being a security risk directly above the code block.

[guardrex]

Thank you, @copilot! Nice job!!! 😄🙈😆

[guardrex]

@wadepickett @tdykstra ... This is my first time asking Copilot to write an article from scratch. However, I was fairly explicit with my prompt. In the future, I'll relax my prompt to see what it can do for me on its own.

This hit me ...

New changes require approval from someone other than the last pusher. Approvals from users that collaborated with the coding agent on changes will not satisfy review requirements. At least 1 approving review is required by reviewers with write access. Approvals from users that collaborated with the coding agent on changes will not satisfy review requirements.

... collaborated with the coding agent on changes will not satisfy review requirements ...

😖

I didn't generate the PR or make any commits to it. This rule is too strict. It will slow down work when the issue is much simpler than this (e.g., fixing a small coding error, phrase, or misspelled word).

[guardrex]

@copilot ... Apply my suggestion for Line 6.

[Copilot]

@copilot ... Apply my suggestion for Line 6.

That change was already applied in the previous commit — line 6 currently reads monikerRange: '>= aspnetcore-8.0'.