Support Blazor 7 state management

[rockfordlhotka]

The new CSLA 8 state management capability doesn't work in .NET 7, and so it is necessary to continue to provide the old Blazor 7 context manager as an option for apps still targeting Blazor 7.

This is via feedback from @mtavares628

[rockfordlhotka]

To use the .NET 7 context manager, use this configuration:

builder.Services.AddCsla(o=>o
    .AddAspNetCore()
    .AddServerSideBlazor(so => so.UseInMemoryApplicationContextManager = true));

[swegele]

Do you have a brief summary somewhere of the differences in the .NET 8 context manager?

[swegele]

I see from this that the .net 8 thing is related to your idea of the session id in cookie mechanism.

The use of that cookie would blow up my blazor server app which is wholly dependent upon the CircuitId and NOT cookies of any kind - therefore each of the browser tabs are completely independent. If all of a sudden CSLA is using cookies to store user context then won't I get cross-tab data polination? That would be bad.

I guess what concerns me is that by introducing cookies and sessionid - and tying that to .NET 8 (arbitrary relationship) - eventually the .NET 6 and 7 (non-cookie) mechanism will go away and I'm hosed.

[rockfordlhotka]

I don't intend to remove the in-memory context manager, as it is a good option for a Blazor server app that does not use any of the new Blazor 8 render mode features.

Were an app to use the new Blazor 8 render features (like mixing a server-static page into the app, or enabling server pre-rendering of pages) then you either

1. Can't use LocalContext or ClientContext
2. Need to use the new context manager and session subsystem

This is because Blazor 8 creates/destroys DI scopes any time you switch render modes, or for each individual server-static page (including pre-rendering). So the old DI (in-memory) way of maintaining per-user state is absolutely unavailable in these scenarios.

Fortunately, it is still possible to write a Blazor 7 style app in Blazor 8 - just turn off all the new render features. Then you can keep using the in-memory context manager because the DI scope for each user is reliable.

[rockfordlhotka]

Do you have a brief summary somewhere of the differences in the .NET 8 context manager?

My intent is to write a doc in the /docs directory that covers upgrading to CSLA 8, and that'll include talking about Blazor 8 render modes and the consequences of using them (and thus having to use the new context manager).

[swegele]

OK that is comforting...it's a semantics thing making it sound like "if you still want to use the old way you can" which tends to make me nervous like "uh oh when is this going to be retired?"

Do you know if I were to use one and only one .Net 8 render mode (Server Interactive - with circuit) and never switch - would it still act like it does now with .NET 6 blazor server? So is it just the switching?

[rockfordlhotka]

Do you know if I were to use one and only one .Net 8 render mode (Server Interactive - with circuit) and never switch - would it still act like it does now with .NET 6 blazor server? So is it just the switching?

Yes, that's exactly right. If you create a Blazor server project using the .NET 6/7 project template, then just update it to .NET 8, it will continue to work exactly like it did before, where all pages are server-interactive without pre-rendering. In that case you should use the in-memory context manager, because the per-user DI scope is reliable.

You can do this with the the new Blazor Web App project template too - just turn off per-page render modes and set the project to be server-interactive. (I haven't tested this - so you might also need to manually turn off pre-rendering, I'm not 100% sure)

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.