-
Notifications
You must be signed in to change notification settings - Fork 90
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
State platform v2 (asynchronicity and browser-side state mutation) #150
Comments
Yeah this is a great idea! I think the server side stuff should stay as is, because async is already fully supported there, and then an integration on the client side with async components should be great! Of course, we'd also need to support that when we actually render the components on the server, but that shouldn't be a problem. As for streaming, this is also definitely something I want to set up. There's already some WS stuff on the client side for hot reloading, so similar code could be reused for this. Then it'd just be a matter of setting this up with all the server integrations. |
I believe we're talking about two different kinds of streaming here. What I was thinking of was something like https://dev.to/tigt/the-weirdly-obscure-art-of-streamed-html-4gc2 using HTTP chunked transfer encoding. The way this would work (and also the way ReactJS works too IIRC) would be once a suspense boundary resolves, a snippet of html and some inline js would be sent over the stream and then sycamore would insert it into the right place. Here's another post that describes how this works in React: reactwg/react-18#37 |
I think we are talking about the same thing, but would this use the same HTTP connection stream? If so, I reckon WS could be very useful for inbuilt realtime operations (maybe a supplementary library). Either way I'd like to hold off on streaming until the islands system is done, because I think there'll be a lot of integration there. Async components I'm happy to go ahead with after I've finished removing |
|
Alright, here are my more formal thoughts on this.
This should pretty much cover everything this issue focuses on, and, for that reason, I'm going to appropriate this for v2 of Perseus' state platform, which will have a strong focus on browser-side state and asynchronicity. @lukechu10 does this basically cover everything you're talking about? I'm aware I haven't really addressed proper streaming, though I don't think this would convey any real benefit to Perseus (or any Wasm framework) at this stage, since Wasm is still unchunked (something I intend to deal with in 2023). The main network bottleneck would be getting the runtime necessary to handle streaming to the browser in the first place. Delayed state, however, does provide a very satisfactory solution (for me at least) to the problems of very large state. There is also an argument that the render config should be fetched with a separate request, although this may require intertwining the render context with the Perseus router in a way that could be very technically complex. Hopefully, it will be fairly straightforward, and this will likely reduce the volume of bytes sent on initial page loads substantially (since the render config, which is basically an object defining all the routes in an app) has to be sent with every initial load right now. |
Suspense
and async components
Note that this is conceptually, but not functionally, blocked by #225. Development on this will proceed even before that's fixed, if necessary. |
I have made a substantial miscalculation: delayed state is a terrible idea! As it stands, commits relating to this will be reverted and the system will not be deployed to Unless there is an explicit feature request for a build-state-only version of delayed state, it will not be implemented. If anyone was counting on this feature, please let me know by opening a new issue! |
See #150 (comment) for details. This reverts commit 8b5da97.
…#242) * feat: created `RxResult` This should facilitate error handling very effectively in suspended state. * feat: created suspense system This needs a lot of cleaning up, but it works! * feat: added nested suspense support and cleaned up * feat: created delayed state macro * feat(wip): progress on delayed state system * revert: removed delayed state system entirely See #150 (comment) for details. This reverts commit 8b5da97. * test: added tests for suspense * feat: added request state and amalgamation to global state * fix: fixed store errors `NotFound` errors were being reported incorrectly, meaning apps not using global state couldn't be compiled. * fix: fixed test for `global_state` example BREAKING CHANGE: global state is now built per-locale, and build state functions therefore take a `locale: String` argument now BREAKING CHANGE: functional plugin actions for failing global state have been removed due to alternate generation systems (you should hook into failed builds instead)
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:
The user described the issue as follows:
Perseus already has
get_build_state
and I think that should stay. However, it would be nice to also have a way to integrate with Suspense and async components.There are quite a few details that would need to be decided upon. The first one would be whether suspense is also awaited on the server side or if it is purely a client side construct. Some information on how this is handled in SolidJS (a similar JS library) is available here: https://github.com/solidjs/solid/tree/main/packages/solid-ssr
Another exciting possibility would be SSR streaming. This page (https://nextjs.org/docs/advanced-features/react-18/streaming) describes how NextJS does it with React.
Lastly, how would this work with the existing
get_build_state
? Should it be recommended to perform data-fetching withget_build_state
or usingSuspense
?I'll be willing to work on this but since the scope of this issue is so large, we'll probably need to do this in multiple steps. I can also give guidance on Sycamore's internals/implementations if needed.
Tribble internal data
dHJpYmJsZS1yZXBvcnRlZCxDLWVuaGFuY2VtZW50LGF1dGhvci13aWxsaW5nLXRvLWltcGw=
The text was updated successfully, but these errors were encountered: