Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Global state #119

Closed
arctic-hen7 opened this issue Jan 20, 2022 · 2 comments
Closed

Global state #119

arctic-hen7 opened this issue Jan 20, 2022 · 2 comments
Labels
author-willing-to-impl The author of this issue is willing to try to implement the solution themselves. C-enhancement Category: enhancement tribble-reported This issue was reported through Tribble.

Comments

@arctic-hen7
Copy link
Member

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=

@github-actions github-actions bot added author-willing-to-impl The author of this issue is willing to try to implement the solution themselves. C-enhancement Category: enhancement tribble-reported This issue was reported through Tribble. labels Jan 20, 2022
@arctic-hen7
Copy link
Member Author

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 added a commit that referenced this issue Jan 20, 2022
This removes ambiguity in preparation for #119.
@arctic-hen7
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
author-willing-to-impl The author of this issue is willing to try to implement the solution themselves. C-enhancement Category: enhancement tribble-reported This issue was reported through Tribble.
Projects
None yet
Development

No branches or pull requests

1 participant