State freezing

[arctic-hen7]

This issue is requesting an enhancement to Perseus. Details of the scope will be available in issue labels.
The user described the problem related to this request as follows:

Right now, Perseus apps are like nearly every other app built with any reactive framework, they have ephemeral state. In other words, their state disappears if the user opens the app in a new tab, reloads the page, etc. Now, there are plenty of workarounds for this, like putting state in IndexedDB and the like, but these require a good amount of manual effort.

The user described the issue as follows:

Perseus currently supports a reactive template state store, and will soon support a global state store as well. When these two are combined, they represent the entire state of an app built with the MVC pattern, which means that, if we could serialize them to a String, that String would represent the entire state of the app, and it could be restarted from scratch in the exact same state. This is an extremely powerful idea, especially if it were implemented automatically in Perseus. This would require a new .make_unrx() method on reactive structs (which should be quite simple given the originals must be Cloneable) so that the reactive state could be turned into something that can be serialized. By adding a method .freeze() on the RenderCtx that ran this on all its component states and brought everything together in one single massive String, we could then save this somewhere. In the browser, the most obvious location is in IndexedDB of persistent storage (the latter of which requires user-granted permissions). Obviously, that saving code will be hefty, so it should be feature-gated, but this would allow apps to, at a time of their choosing, get the RenderCtx with the new get_render_ctx!() macro and then run .freeze() to save their entire app's state. Then there's the problem of re-hydrating all that state, which can be done actually quite trivially, it would just be a matter of, if the feature flag is enabled (we might call this freeze), extracting the state from the storage location and deserializing it, making everything reactive. Then, we could run the app with that. The big question is how long each of these processes will take, and to what extent they'll impede viewing the site. With the latter, it should definitely be performed after the user can see content, but before it's made reactive. As for the freezing itself, we'll have to see. Regardless, this feature would enable building extremely complex apps with Perseus extremely efficiently, and it would make us the only framework in the world (I think) to support saving the entire app's state automatically.

• The author is willing to attempt an implementation: true

Tribble internal data

dHJpYmJsZS1yZXBvcnRlZCxDLWVuaGFuY2VtZW50LGF1dGhvci13aWxsaW5nLXRvLWltcGw=

[arctic-hen7]

Adding to all that, we could even support custom transports through a trait that could allow saving to anywhere, maybe even a remote server.

[arctic-hen7]

It looks as if Rexie will be good for working with IndexedDB!

[arctic-hen7]

Okay, this is all ready in the general case, though I haven't set up any feature flags for state freezing generally. However, when I set up an IndexedDB integration, that will be feature-gated.

[arctic-hen7]

The only thing left to do here is make things work when the app was frozen on the same page as the user is currently on, because we need to reload that template, but Sycamore doesn't (yet) have a way to do that. Until then, I think this can be achieved by some refactoring in the Perseus engine so that we can recall the router imperatively.