Update ResourceCollectionProvider to take advantage of Declarative persistent component state

[ilonatommy]

Follow-up for #60634.

Description

ResourceCollectionUrl saving and restoring responsibility is moved to PersistentServicesRegistry.

[ilonatommy]

@javiercn, is it possible that we are not restoring the state for webassembly interactive at all? We have it done for server when the circuit is set up:

aspnetcore/src/Components/Server/src/Circuits/CircuitHost.cs

Line 772 in 0508333

await appLifetime.RestoreStateAsync(store);

but I cannot find any RestoreStateAsync calls in wasm render mode context?

aspnetcore/src/Components/WebAssembly/WebAssembly/src/Hosting/WebAssemblyHost.cs

Line 140 in 0508333

await manager.RestoreStateAsync(store);

is the only one but it's not triggered on "rehydration" after prerendering.

[javiercn]

@ilonatommy not sure what's going on here, but we have tests covering this.

You could try debugging the sample project to figure out what is going on

[ilonatommy]

Summary what's going on:

Key in prerendering for Microsoft.AspNetCore.Components.ResourceCollectionProvider.ResourceCollectionUrl is different than the key for WASM rendering.

There are 2 reasons I suspect:

• ResourceCollectionProvider is defined in "shared", so in prerendering it belongs to Microsoft.AspNetCore.Components.Endpoints assembly and in WASM rendering it belongs to Microsoft.AspNetCore.Components.WebAssembly.
• version string differs between prerendering and WASM, Version=10.0.0.0 vs Version=42.42.42.42 (dummy version for WASM assemblies) and PublicKeyToken.

Even if we skip the version by using simplified name keyType.Assembly.GetName().Name instead of keyType.Assembly.FullName, the problem with changing assembly name on the rendering boundary persists.

Logs for using the simplified assembly name:

[ComputeKey] Using assembly: Microsoft.AspNetCore.Components.Endpoints, type: Microsoft.AspNetCore.Components.ResourceCollectionProvider, propertyName: ResourceCollectionUrl, inputString: Microsoft.AspNetCore.Components.Endpoints.Microsoft.AspNetCore.Components.ResourceCollectionProvider.ResourceCollectionUrl
[ComputeKey] computed key: reRoeSH0zUNg1lV5T25mU63ifKBQDmwekOTpUjGhOzw=
[Persist] Persisting Key: reRoeSH0zUNg1lV5T25mU63ifKBQDmwekOTpUjGhOzw= for Declared type: Microsoft.AspNetCore.Components.ResourceCollectionProvider, Runtime type: Microsoft.AspNetCore.Components.ResourceCollectionProvider Value: ./_framework/resource-collection.7sl7m.js

MonoPlatform.ts:234 [ComputeKey] Using assembly: Microsoft.AspNetCore.Components.WebAssembly, type: Microsoft.AspNetCore.Components.ResourceCollectionProvider, propertyName: ResourceCollectionUrl, inputString: Microsoft.AspNetCore.Components.WebAssembly.Microsoft.AspNetCore.Components.ResourceCollectionProvider.ResourceCollectionUrl
MonoPlatform.ts:234 [ComputeKey] computed key: OJ5IulA9AwVvEZZuXoXvRFiqSKythSxVh7f6TDMswl4=
MonoPlatform.ts:234 [Restore] Failed restoring Key OJ5IulA9AwVvEZZuXoXvRFiqSKythSxVh7f6TDMswl4= for Declared type: Microsoft.AspNetCore.Components.ResourceCollectionProvider, Runtime type: Microsoft.AspNetCore.Components.ResourceCollectionProvider.

[javiercn]

@ilonatommy good catch.

This is something that we solved for other types (AntiforgeryStateProvider) relying on the public abstraction, but I don't think we want to add a public abstraction for this type, as it's completely internal.

We should figure out what we want to do here, but there are some options like explicitly providing a key in these cases where stuff is "shared".

We want to support passing information across boundaries without having to require any public API, we just need to tweak the way we do this.

I think we still want to use the full name to compute the key by default as that's the common case and guarantee's us that we don't squat over types that have the same name.

[Copilot]

Pull Request Overview

This PR updates the handling of persistent component state for ResourceCollection by moving its saving and restoring responsibility to PersistentServicesRegistry.

• Update ResourceCollectionProvider to use a persistent state attribute and remove internal state persistence logic.
• Register ResourceCollectionProvider for persistent state registration in both WebAssemblyHostBuilder and RazorComponentsServiceCollectionExtensions.
• Refactor key computation in PersistentServicesRegistry to ensure canonical assembly names are used.

Reviewed Changes

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

Show a summary per file

File	Description
src/Components/WebAssembly/WebAssembly/src/Hosting/WebAssemblyHostBuilder.cs	Registers ResourceCollectionProvider as a singleton with an added persistent service registration.
src/Components/Shared/src/ResourceCollectionProvider.cs	Removes internal persistent state logic and switches to a property marked with SupplyParameterFromPersistentComponentState.
src/Components/Endpoints/src/Rendering/EndpointHtmlRenderer.cs	Updates the code to use the new property setter instead of a method call for setting the URL.
src/Components/Endpoints/src/DependencyInjection/RazorComponentsServiceCollectionExtensions.cs	Registers ResourceCollectionProvider as a scoped service with persistent service registration.
src/Components/Components/src/PersistentState/PersistentServicesRegistry.cs	Refactors the ComputeKey method to use a canonical mapping based on assembly names.

Comments suppressed due to low confidence (2)

src/Components/WebAssembly/WebAssembly/src/Hosting/WebAssemblyHostBuilder.cs:310

• ResourceCollectionProvider is registered as a singleton in WebAssemblyHostBuilder, while in RazorComponentsServiceCollectionExtensions it is registered as scoped. Consider aligning the DI registration lifetimes across the project to avoid inconsistent behavior.

Services.AddSingleton<ResourceCollectionProvider>();

src/Components/Shared/src/ResourceCollectionProvider.cs:21

• [nitpick] The previous registration of a persisting callback on the ResourceCollectionUrl setter has been removed. Please ensure that the external registration via RegisterPersistentComponentStateServiceCollectionExtensions fully covers the intended persistence behavior to avoid potential state loss.

get => _url; set { ... }