Blazor persistent services: document singleton registration requirement for WebAssembly clients - #37412
Conversation
…vices Fixes #37411: Updates the "Serialize state for services" section to clarify that for InteractiveAuto and InteractiveWebAssembly render modes, the service must be registered as a singleton in the .Client project's Program.cs. Adds "Server project service registration" and "Client project service registration" subsections with clear examples and explains why singleton registration is required on the client.
|
@copilot ... Accept my suggestion for Line 221. |
That change was already applied in 9b7d98a — line 221 matches the suggestion exactly. |
guardrex
left a comment
guardrex
left a comment
There was a problem hiding this comment.
@oroztocil ... AI did a nice job with this one. If you approve, we can merge this now. It won't let me approve/merge it without another review after I've done anything with Copilot due to the new restrictive merging rules 💸😩.
The update looks good. Let me confirm with @javiercn that we want to use this as official recommendation, or proceed otherwise (e.g. change the implementation to not require this approach). |
The "Serialize state for services" section only showed a scoped server registration, which led users to register the service as scoped on the
.Clientproject as well—causing aDirectScopedResolvedFromRootExceptionat runtime underInteractiveAuto/InteractiveWebAssemblyrender modes.Root cause:
ComponentStatePersistenceManageris a singleton on the client and resolves dependencies from the root service provider. A scoped registration throws in Development, and even without the exception, produces two separate instances—so restored state never reaches the component's injected instance.Changes to
prerendered-state-persistence.md:Programfile example into two subsections:AddScoped+RegisterPersistentServiceexample, with context clarified to "server project."Internal previews