App setup RFC #326
App setup RFC #326
Conversation
|
|
||
| - This proposal exposes lower-level control to users. Fine for advanced use cases, but makes it easier to introduce performance footguns if not used carefully. | ||
| - This proposal introduces a new pattern that, while modelled after similar patterns in other frameworks, has a unique design due to Astro's constraints | ||
| - This proposal **DOES NOT** solve a common problem for sharing state via `Provider`s. It's extremely likely that people will expect this feature to do that because you can setup a Provider. However, Providers in this proposal **ARE NOT** stateful between islands—updates to one Provider instance will not automatically propogate to other Provider instances unless specifically architected to do so by the user. |
There was a problem hiding this comment.
I understand the desire to avoid feature-bloat, but presumably you are thinking about this. Shared context in React is one very desirable feature. We can skip that for now, but it would be good if you have an idea of what that might look like so that this feature can be a stepping stone and that is not a completely different feature, if that makes sense.
There was a problem hiding this comment.
Yeah that totally makes sense. This proposal is certainly not blocking an implementation of shared context in the future, since a prototype of that is what I extracted this proposal from. I was hoping to avoid this conversation being focused on shared state because there's still a lot to figure out there, but users asking to hook into vue.use comes up almost every day.
There was a problem hiding this comment.
I would even be open to not implementing this appEntrypoint proposal for React/Preact until shared state lands. It's possible this might just be a footgun until Providers can be singletons that only run once.
There was a problem hiding this comment.
I think holding off on React makes sense. I haven't seen as much of a demand for the "pyramid of providers" pattern as there has been for Vue .use() so far.
|
It would be quite neat if there was a way to specify setup code that only gets loaded on server side or client side (like with the game engine melonJS, it would be cool to render the game to a static image on the server side, render that on the initial page load, then on the client side replace it with the actual game after the page has mounted) See Also: melonjs/melonJS#1134 (to me this issue appears quite difficult to implement atm) |
|
Update: After discussing this during [Community Call] October 4, 2022, we decided that it was too early to abstract this concept into a core Astro feature. As such, I have chosen to withdraw this RFC. Thankfully, this can all be accomplished through our integration API (aka "in userland")! The plan is to implement this proposed behavior in the |
This should be possible now, even without a feature like this! Feel free to ping me on Discord and I can walk you through it. |
Summary
This RFC proposes a unified interface that provides a hook into island setup. User-provided hooks will run for both server rendering and client-side hydration.
The primary motivation is unblocking
vue.use, but there are other use cases as well.Links