Global state

[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 supports generating state for templates, but not for the whole app. And yet, there are many cases (most documented with people hoping to do this with NextJS) in which this feature would be extremely beneficial.

The user described the issue as follows:

Perseus should support generating state that can be provided to all templates in some way. There are multiple possibilities for how we could do this, the most obvious being a way to initialize the global state used by templates. Having tried this briefly, it leads to problems with Warp, multi-threading, and interior mutability which all play off each other and can't easily be solved. The second option would be to provide a second argument to templates (which can be abstracted and made completely optional through the #[template] and #[template_with_rx_state] macros, making this a non-breaking change) for the globally generated state. I think the best way to handle this would be to rename the current global state to TemplateStateStore (which we can do before v0.3.3) to indicate that it's for template use, and then we could create a new global state system that depends on a struct that the user provides. So, very similarly to how they'd do it for a Template<G>, they would create a GlobalStateCreator with the desired strategies registered, and they could then provide that to define_app!. From there, the rest is very simple, until we encounter one major problem: reactivity. If the new global state is to be reactive (easily set up with #[make_rx]), we introduce the problem of build interference, whereby one template can modify the global state so that it's no longer what another template expects! We can ask users not to do this when G::IS_BROWSER is false, but I don't like how non-obvious that approach is. Instead, I think it would be much better if we instead passed around a non-reactive version of the global state and then made it reactive only at the last moment. That way, each template would get its own isolated instance of state at prerendering, and then they'd all share one reactive instance in the browser. Finally, the strategies that we should support for generating global state are: build state, request state, and revalidation. There's no point supporting build paths and incremental generation because they both require multiple paths, and we're generating for the root of the app. Notably, this similarity to the Template<G> build process may open the door to a nice refactor of that system (which is overly complex and unusable at present).

• The author is willing to attempt an implementation: true

Tribble internal data

dHJpYmJsZS1yZXBvcnRlZCxDLWVuaGFuY2VtZW50LGF1dGhvci13aWxsaW5nLXRvLWltcGw=

[arctic-hen7]

Actually, we're not going to be able to pass the global state as the second argument because of the #[component] annotation. What I can do though is make this supported on the template_with_rx_state macro (by making the #[component] annotation implicit there) and then I can change this in the usual macro in the next major release.

[arctic-hen7]

A few changes to the original proposal: we're using #[template2(...)] now, which will supersede the original #[template] macro entirely in v0.4.0, and I've only implemented a build-time global state creator because I struggle to see the real benefit of adding the extra complexity of request state and revalidation. I'm happy to revisit that in the future though.