State hydration

[arctic-hen7]

Right now, Perseus is fundamentally a tool for generating some initial state in a variety of ways and then passing that to a template, which then generates a view to display to the user. But, what if state had a continued role? The MVC style of UI programming can be used with Perseus, but I think it would be cleaner and more powerful if Perseus could make state reactive, so that templates could then base their entire data requirements around their state.

This would a potentially very powerful approach, and it makes the idea of state much clearer to me personally. Of course, this is a more prescriptive development pattern than Perseus allows today, so I think this might be best achieved with a macro alternative to perseus::template like perseus::mvc_template.

From there, my next inclination is to create some kind of global mutable state store for all templates, which would allow templates to retrieve their state again if the user navigates back to them. In theory, given this is all JSON-compatible, that state could even be stored in something like IndexedDB in the browser.

Thinking of #4, which would allow many templates to operate in a single UI, a global state store would allow these to communicate with each other in a quasi-asynchronous fashion, as if synchronizing state across threads. Message passing could also be implemented for that as an alternative pattern.

This is all very interesting stuff (to me), and I think it's worth implementing as much of this as possible in the next few releases. Most will likely have to wait until Sycamore has deep state reactivity, but I think this model of hot state could be very powerful not just for apps generally, but also for development, as it would allow what is effectively HMR in Rust. The development bundle would be able to write state to IndexedDB and then read it back after a reload to restore a template's state. This might even be able to extend to an extra development store that holds all input values, button states, etc., which would allow HMR across rebuilds, reloads, and even browser closures if you let the IndexedDB data persist, which is pretty crazy!

This issue will be a tracking issue for the many aspects of what I've just walked through, and I hope most, if not all, of this will be ready for v0.4.0!

[arctic-hen7]

If anyone has anything further to add to this conversation, please don't hesitate, I am very open to ideas on this pattern and extensions to it!

[arctic-hen7]

Okay, as of now, reactive state is fully functional through the #[make_rx] macro, which can make any struct fully reactive (including support for nesting), and the #[template_with_rx_state] macro, which will make a template's state reactive and register it in the global store before handing it over. This also means that, if the user goes index -> about -> index, the second visit back to index will retain the state from the original, including any modifications. This makes state fully reactive in Perseus!

State freezing (which would allow quasi-HMR support) is not implemented yet, I'll open a separate issue for that, and then the next big thing on this is global state initialization, whereby users would be able to use all the relevant state creation strategies (build state, request state, etc.) on the whole app. That will be a new issue too.