Re: Flowing-State-in-Blazor-8

[swegele]

@rockfordlhotka
Appreciate your last 2 blog articles about the new Blazor deployment styles in .NET 8 and the subsequent issues with state.
Flowing-State-in-Blazor-8

For years (too many to admit) I've enjoyed checking in regularly on your blog and finding road signs that let me know what is coming in the near future that may be of concern to me and other LOB app devs.

I wanted to add a thought related to your solution. Indeed, you already mentioned a slight concern about using a sessionid cookie.

One of the REALLY huge benefits that we've realized by using Blazor Server Side (?Server Interactive?) is that there is no SessionID cookie. Unlike ASP.Net WebForms - each browser tab gets it's own independent Circuit. This allows each Browser Tab to act completely independently of other tabs. Now it is possible to have:

1. One user open multiple tabs having independent app logins going at the same time. (user can login to view Item num 1 and on another tab login to view Item num 2)
2. Two users sitting at the same PC interact with the app at the same time in their own tab (e.g. trainer/trainee)
3. Other use cases I won't discuss here

As you know cookies are a cross-tab resource. I recently verified this by having one user login with multiple tabs while using the Azure Load Balancer solution with session affinity turned on. The Azure load balancer puts a cookie on the browser and all the tabs pointing to the site get sent to the same server.

So my long winded point is that requiring the use of a session cookie would cause the (perhaps unintended) side effect of all browser tabs sharing the same session. With your idea still in draft, I figured I'd put this bug in your ear as this is maybe some unique use of blazor server side that you hadn't thought of.

[rockfordlhotka]

Thanks @swegele!

There is a cookie scope that is per-tab, and that's what I'm using in the Blazor8State project, so it doesn't interfere with having different user sessions by having different tabs.

I've explored some other ideas around maintaining a session id value that is consistent in server-rendered, server-interactive, and wasm-interactive, but a cookie appears to be the only answer.

[swegele]

Good question, which makes me realize how confusing things are going to get as now we have two separate server side technologies! Ugh. As if two types of Blazor wasn't enough...now we have 3!

I have not tried using local/session storage with the new blazor server .Net 8 thing.
I've only used it in the "old" Blazor Server things (which uses the SignalR circuit).

[rockfordlhotka]

That's the point of my blog posts - how to maintain some consistency between all THREE render models as they switch automatically (and dynamically) from page to page, or even as the user sits on one page!

Very magical and awesome, but with some real side-effects!

[swegele]

If writing/reading from there doesn't work for the new Blazor Server (non-signalR thing) then I wonder if you could make it adapt in situ-

The blazor server side (with signalR) and Blazor WASM could store the session id value in session storge...otherwise store it in a cookie?

[rockfordlhotka]

I think that's something the app developer would need to choose up front, because only they will know if they are including any server-rendered pages in their app.

In the (new) default template for a Blazor App you get all three. Home is server-rendered, as is the weather page (plus streamed content). The Counter page starts as server-interactive and switches to wasm-interactive - potentially while the user is sitting on the page!