[Blazor] Platform Initialization strategy around services within different Blazor flavors

[javiercn]

There are a bunch of services we require initialization for in different platforms:

• NavigationManager
• AuthenticationStateProvider
• ComponentApplicationLifetime

Every time we are in this situation we have to be making changes on each platform "host" to include code specific to those services.

In addition to that, third-party components need to come up with their own strategy around how they initialize services.

As we add more services, this doesn't really scale up. The proposal here is to provide a new primitive that we use and that third-party code can use too to initialize their components. We will move our own initialization code to use this new primitive and enable third-party customers/libraries to also implement it.

The way this works at a high level is:

• We will provide an "Initializer" interface that we will resolve from DI.
• Our TContext will be what the host platform passes to the initializer. In the three cases we care about right now:
  • HttpContext -> For when we are doing prerendering.
  • Circuit -> For when we are rendering Blazor server.
  • WebAsemblyHost -> For when we are rendering on a webassembly context.

Blazor desktop will likely be a 4th option on the list above.

During initialization we will resolve a list of all the Initializers and run them in order (order is important here because they can have service dependencies between them (I actually run into this at one point with auth and NavigationManager))

As an addendum to this issue, we want to support also initialization on the JS side of things:

• Loading library scripts at the right time.
• Configuring how Blazor wasm/server JS options.
• Customizing Blazor wasm boot process

[ghost]

Thanks for contacting us. We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.