[Blazor] JS root component registration

[javiercn]

Description

Delays the execution of afterStarted until the runtime has been initialized so that customers can invoke methods within the Blazor instance.

Fixes #37074

Customer Impact

This is feedback that we got in the RC where customers where not able to use two of the features that we built (JS Root Components and JS Initializers) together because the blazor webassembly host wasn't ready at the time.

It prevents customers for using JS initializers to initialize their component libraries in JS effectively, which is one of the goals the feature was designed for.

Regression?

• Yes
• No

Risk

• High
• Medium
• Low

We have end to end tests in this area, and I've verified manually that the call is now emitted at the right time.

Verification

• Manual (required)
• Automated

Packaging changes reviewed?

• Yes
• No
• N/A

[pranavkm]

This makes sense, but it'd odd that this wasn't done in the initial implementation. Can we have @SteveSandersonMS sign off on this in case he's aware of a reason this was separately handled?

[SteveSandersonMS]

it'd odd that this wasn't done in the initial implementation

It's the same as for any JS interop call. It's the developer's responsibility to wait until their .NET application is ready before making calls into it from outside.

People can do this using Blazor.start, or another easy pattern is to place a JS interop call from .NET to JS inside Program.cs, e.g.:

await JS.InvokeVoidAsync("doMyJSInitialization");

// alternatively:
await JS.InvokeVoidAsync("import", "./myJsInitializationModule.js");

I'd err on the side of not changing this as a special case for JS root components based only on one customer request, especially given that they also said:

This seems low priority to me, since we do have a solution already, but I do think it would be helpful.

Does that sound reasonable @javiercn?

[javiercn]

It's the same as for any JS interop call. It's the developer's responsibility to wait until their .NET application is ready before making calls into it from outside.

The issue here is not that the .NET application is not ready, but rather that the host is not yet built (on the .NET side).

People can do this using Blazor.start, or another easy pattern is to place a JS interop call from .NET to JS inside Program.cs, e.g.:

I don't think that's the case, since the promise returned from start doesn't guarantee that the host has been built?

I think more in general, that people is calling a method on the Blazor object within the result from "Blazor.start" or "afterStarted" (which is virtually the same, since it's the last thing that happens during initialization) and at that point the functions in the Blazor object should be ready to accept being called.

I think the fix is simple and that there is no technical reason for us not to internally wait until the framework setups interop internally (as the fix proposes).

[SteveSandersonMS]

I think the fix is simple and that there is no technical reason for us not to internally wait until the framework setups interop internally (as the fix proposes).

I know we can do it, and I see the fix is simple. My concern is about the wider pattern. Other cases of APIs people can call from JS and might do before the app starts up include:

• JS interop (DotNet.invokeMethodAsync and DotNet.invokeAsync)
• Blazor.navigateTo

There may be others in the future. Should they all wait for the runtime to start? Should it be a random subset of them that do? By adding this behavior to Blazor.rootComponents.add, it becomes more confusing when people have to reason about which of the others will also have this behavior.

That was my reasoning before anyway. After more consideration, I guess some APIs are agnostic to whether the runtime has started (e.g., Blazor.registerCustomEventType) so maybe it's false to act as if all these APIs have the same startup semantics. After more consideration, I'm fine with changing this.

[SteveSandersonMS]

The change at https://github.com/dotnet/aspnetcore/pull/37180/files#r720486550 is important; the other comments are just for clarity.