You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I made a demo which confirms that this is possible and can be automated by transforming input HTML and Promise values into a DSD structure with Promise results deferred to the end of the content, where they can be streamed in any order.
I think this is super cool and would be a powerful optimization technique, especially considering that it can be done mostly automatically, if developers author the right structure. Since @rules_prerender uses shadow DOM heavily and implements its own <Template /> Preact component, I think it would potentially be feasible to make this work automatically.
The prototype I did used tagged template literals, so I'm not sure exactly how this would work with VDom. I suspect we do something like:
lazy() would just make any suspense stuff easier to work with if possible.
I don't think there's a way to easily correlate the <Template shadowrootmode="open" /> component to the world()Promise, but maybe that's fine. I think we could possibly transform the final VDom for the page (or write a custom renderer) which looks for all lazy values, finds the nearest shadow root ancestor, and transforms them to push the Promise HTML to the end of the document. Definitely need to experiment more to see how this can work.
Needless to say this only really makes sense for true SSR. In SSG, there isn't much value to this kind of streaming. We'll want to explore this once we have a real SSR story.
It might also be worth seeing if it's possible to do all these transformations at compile time. If we can do this statically before request time, then basically the entire document can be streamed immediately without invoking user code at all. Only the slots at the end of the document would need to be filled in via SSR. Not sure how feasible that is, especially if SSR'd HTML would want to take advantage of this trick as well, but it's worth looking into at least.
The text was updated successfully, but these errors were encountered:
I recently discovered that it is possible to stream HTML out of order (without hacky client-side JS) using declarative shadow DOM: https://techhub.social/@develwithoutacause/111723544374367628
I made a demo which confirms that this is possible and can be automated by transforming input HTML and
Promise
values into a DSD structure withPromise
results deferred to the end of the content, where they can be streamed in any order.https://github.com/dgp1130/out-of-order-streaming/
I think this is super cool and would be a powerful optimization technique, especially considering that it can be done mostly automatically, if developers author the right structure. Since
@rules_prerender
uses shadow DOM heavily and implements its own<Template />
Preact component, I think it would potentially be feasible to make this work automatically.The prototype I did used tagged template literals, so I'm not sure exactly how this would work with VDom. I suspect we do something like:
lazy()
would just make any suspense stuff easier to work with if possible.I don't think there's a way to easily correlate the
<Template shadowrootmode="open" />
component to theworld()
Promise
, but maybe that's fine. I think we could possibly transform the final VDom for the page (or write a custom renderer) which looks for alllazy
values, finds the nearest shadow root ancestor, and transforms them to push thePromise
HTML to the end of the document. Definitely need to experiment more to see how this can work.Needless to say this only really makes sense for true SSR. In SSG, there isn't much value to this kind of streaming. We'll want to explore this once we have a real SSR story.
It might also be worth seeing if it's possible to do all these transformations at compile time. If we can do this statically before request time, then basically the entire document can be streamed immediately without invoking user code at all. Only the slots at the end of the document would need to be filled in via SSR. Not sure how feasible that is, especially if SSR'd HTML would want to take advantage of this trick as well, but it's worth looking into at least.
The text was updated successfully, but these errors were encountered: