Questions around PersistentComponentState in Blazor

Question

Hi all;

A couple of questions around PersistentComponentState:

First, is PersistentComponentState tied to the SignalR circuit or global to the app? For Blazor render mode InteractiveServer Microsoft says the way to avoid reading in data twice for a page (pre-render and again post-render) is to save it the first time using PersistentComponentState and then the second time just use the data saved off to it.

Is this persisted data global to the app or is it scope level data tied to the session/circuit? Reading the docs it sounds like it's global, but it suggest as the key nameof({VARIABLE}) and for multiple users hitting the same page, they would have the same key.

That will work if the data is per session/circuit. That will have key name conflicts if it is global.

Second, is there any advantage to PersistentComponentState over MemoryCache? Why not use MemoryCache? Is there any downside to doing so? Reading the Microsoft documentation it looks like this is an app global data store, not a per circuit store. So I think MemoryCache is basically the same thing.

The one difference is PersistentComponentState serializes the data to JSON. That's a performance hit if the data stays on the same app, but is critical if that is copied to other instances.

??? - thanks - dave

Answer 1

first you need to understand how pre-render works.

if the blazor app supports pre-render, on the first request, the server creates a blazor app, and runs pre-render event to produce the html content of the app div. the response also contains the blazor javascript bootstrap code. at this point the the blazor app is shut down as the request is completed.

when the page is loaded by the browser, it displays the pre-render html, and runs the blazor bootstrap javascript code. if WASM, it loads the blazor app, and starts it running, or if server blazor create a new server request which opens a circuit and starts a new server blazor app instance.

after the new blazor app starts (WASM or Server), it produces new app html which replace the pre-render html.

now to pass pre-render state to the new blazor interactive instance, the persist data is just rendered on the pre-render page along with the pre-rendered html. when the blazor javascript bootstrap code runs, it detects then persistent data, and sends to the new instance via the circuit or WASM message.

this is why the persist data should be small. it is part of the initial render download, and in the case of server blazor must be sent back to the server.

Answer 2

Hi @David Thielen

After testing the sample code, we can see that PersistentComponentState in Blazor is indeed tied to the SignalR circuit, meaning it persists across reconnects within the same session. It is scoped to the circuit, not global to the entire application. Each SignalR circuit will have its own instance of PersistentComponentState.

Besides, about the comparison between PersistentComponentState and MemoryCache. PersistentComponentState is scoped to the circuit or session, MemoryCache is typically scoped to the entire application domain unless explicitly configured otherwise. Therefore, if you need data to persist only within a SignalR circuit, PersistentComponentState is more suitable. Besides, PersistentComponentState automatically serializes data to JSON, MemoryCache does not provide it, if using memory cache, you have to handle serialization manually.

---

If the answer is the right solution, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Best regards,

Dillion