Consider changing "Blazor component" to "Razor component"/"component"

[guardrex]

Update (2/22)

This is important enough to move to issues for work IMO, so I opened issues at #4830 and dotnet/aspnetcore#40344. These will be quick 🏃 to address.

Original remarks

@danroth27 has ruled that the term "Blazor component" is valid informal naming for Razor components, the official, formal name. See my remarks here ...

dotnet/docs-maui#295

I recommend that in the few spots in framework code where the term "Blazor component" appears that it be changed to either "Razor component" or just "component" to resolve the dual-naming problem and completely align the framework code/API docs with the Blazor docs. I understand that third-parties have picked up on "Blazor component" and started using it; however, consistency in how MS presents what these "components" are among framework code, API docs, reference docs, and tutorials seems like a preferable goal to me. I don't think the following scenarios are the best choice ...

• Every mention in Blazor docs presents both with a slash: "... Razor component/Blazor component ..."
• Mixed use in the Blazor docs going back and forth with some spots using "Blazor component" and other spots using "Razor component."
• Blazor docs adopt one name, currently "Razor component," and the framework code/API docs go a different way, currently mixed use of "Razor component" and "Blazor component."

AFAICT, "Blazor component" only appears in three files here ... usually in comments that will resolve to API docs ...

• https://github.com/dotnet/maui/blob/main/src/BlazorWebView/src/WindowsForms/BlazorWebView.cs
  • Line 18
  • Line 72
  • Line 100
  • Line 127
• https://github.com/dotnet/maui/blob/main/src/BlazorWebView/tests/MauiDeviceTests/Elements/BlazorWebViewTests.cs
  • Line 15
• https://github.com/dotnet/maui/blob/main/src/BlazorWebView/samples/MauiRazorClassLibrarySample/Component1.razor
  • Line 2

If you'd entertain a PR from me to update these spots, I'll open an issue + PR combo and knock it out.

cc: @SteveSandersonMS @mkArtakMSFT @Eilon @davidbritch

UPDATE: I'll pile on here the few instances in the dotnet/aspnetcore repo with the same "Blazor component" naming in case you allow me to submit a separate issue + PR to update them.

• Test app component renders the term: https://github.com/dotnet/aspnetcore/blob/main/src/Components/test/testassets/BasicTestApp/ExternalContentPackage.razor
• One mention in a code comment that won't appear in API docs: https://github.com/dotnet/aspnetcore/blob/main/src/Components/Web.JS/src/Rendering/LogicalElements.ts
• One mention for API docs: https://github.com/dotnet/aspnetcore/blob/main/src/Components/WebView/WebView/src/WebViewManager.cs
• Test app component renders the term: https://github.com/dotnet/aspnetcore/blob/main/src/Components/test/testassets/BasicTestApp/DynamicallyAddedRootComponent.razor

Perhaps, a special case is in the following files that use Blazor-Component-State, but this might be by-design (i.e., Razor-Component-State isn't welcome for some reason in these cases):

const blazorStateCommentRegularExpression = /^\s*Blazor-Component-State:(?<state>[a-zA-Z0-9+/=]+)$/;

Assert.Equal("<!--Blazor-Component-State:e30=-->", content);

• https://github.com/dotnet/aspnetcore/blob/main/src/Components/Web.JS/src/Services/ComponentDescriptorDiscovery.ts
• https://github.com/dotnet/aspnetcore/blob/main/src/Mvc/Mvc.TagHelpers/test/PersistComponentStateTagHelperTest.cs