[Blazor] Update discovery APIs and automatically configure the endpoints based on the discovered RenderModes

[javiercn]

#46980

[SteveSandersonMS]

Can we open a discussion about the pros and cons of automatically wiring up websocket/wasm endpoints based on the existence of components with particular render modes? I know you've done a lot of work to enable that here, however developers still have to understand what's going on and could be at risk of misconfiguration. For example, the default setup would automatically switch on the WebSocket listener if someone adds an Auto-mode component anywhere in the whole app (and even if one gets added in a new version of an RCL? that seems very troublesome), without making this obvious to the app owner who might never want to support Server components.

We could potentially simplify this a lot (remove a lot of implementation that would have to be maintained) and take a more risk-averse position on opening endpoints with only a tiny extra bit of explicit code in Program.cs.

If the default project template was a bit more explicit:

-app.MapRazorComponents<App>();
+app.MapRazorComponents<App>()
+    .EnableServerRenderMode()
+    .EnableWebAssemblyRenderMode();

... then we could remove lots of the rules about how the endpoint registrations are detected and how you can override that via combinations of UseServerRendering/UseWebAssemblyRendering/UseStaticRendering. It would be extremely obvious that you get the WebSocket listener or wasm static file serving if and only if you have the corresponding explicit opt-in.

Again, I know it's painful to even have this discussion given the amount of code already written and how invested you may feel in the autodetection design. We could always add the autodetection in the future (e.g., app.MapRazorComponents<App>(detectRenderModes: true)).

Definitely also interested in opinions from others (cc @danroth27 @mkArtakMSFT) to try to stay objective about product goals.

[SteveSandersonMS]

Will this be unit-tested?

[javiercn]

I don't plan to. This is covered by our E2E tests and will be source generated by default. This is here as a fallback.

[SteveSandersonMS]

What are the scenarios where someone would disable the source generator?

[javiercn]

Are there? I see the SG similar to the Razor SG. It's part of the core experience, not something you opt in.

[javiercn]

Once the source generator is available, we won't use this code path at all.

[SteveSandersonMS]

Once the source generator is available, we won't use this code path at all.

OK that's great - I'm guessing that means we'll be able to remove it and won't have to worry about maintaining two implementations. If that's not the case it would be great if you could correct me on this.

[SteveSandersonMS]

Nice! Added a couple of questions which it would be great if you could answer. The nitpick code remarks I'll leave to your judgement.