Blazor state management

[JacoJordaan]

Question I am looking into state management in Blazor to keep state between pages and also persisting state for complex csla objects. In memory state management should work easily with csla objects (I think), since the objects can just be kept in memory and assign to the page on initialization.

For persisting state to local storage or database, I am not sure how this would work? I am thinking in the direction of serialization of object graph for persistance and then in some way be able to deserialize it back into object for retrieval.

What would be the recommended approach on this?

Version and Platform CSLA version: 5.1.000 OS: Windows, Linux Platform: Blazor Server and Wasm

[rockfordlhotka]

This is really a non-issue because Blazor just makes it work. Blazor development is directly analogous to Windows Forms, WPF, UWP, Silverlight, iOS, and Android client development - it is a smart-client technology.

Smart client platforms don't have Alzheimer's like the web. That've always maintained state throughout the life of the app (until the user closes the app).

All these fancy state management concepts exist to overcome limitations of the web app models. Those limitations don't exist in smart client scenarios, and so there's never been a need for state management schemes.

[JacoJordaan]

@rockfordlhotka , thanks, I agree.

There is a case for keeping state for a page e.g. a search page where you fill in your search criteria and get results back. From there on you normally navigate to a more details page. When you come back to the search page, you want to have the same criteria still in place.

I have borrowed some concepts from Jeremy Likness (https://blog.jeremylikness.com/blog/blazor-state-management/) to handle this and it is working well for in memory state class.

For my use case I don't think it is required to persist the state to the browser's cache. If I need to go that route then I will need to look at serializing the csla object to text and save this in browser's cache. Deserializing it from browser's cache into new object when required. Almost like what the dataportal is doing at the moment. Not sure if this is possible?

[rockfordlhotka]

I never assume Blazor is running in the browser, because I author/debug in server-side and then deploy client-side.

Because Blazor is stateful, you can just use a static cache, or better yet the .NET caching subsystem.

[rockfordlhotka]

You can also look at what I've done in ProjectTracker to avoid page-switching for list lookups (the inverse of what you are describing).

I'd also suggest that you should think carefully about not reloading a search list between edits. Other users may have changed data, and the current user will have changed data, so you need to think about how to get those changes reflected in any cached list of data on the client.

[JacoJordaan]

@rockfordlhotka , thanks, I did check out the work ProjectTracker previously and I like the approach. My scenario is a bit different in this use case.

I have search criteria which I use the state management and not the search results, so I am avoiding the changed data issue.

While reading your post I realised that I used a Singleton instead of a Scoped service on the Blazor server side for the state.